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ABOUT THE SEMINAR 


This is the second in 
developers and users 1 
within the Department 
evaluation of commercial 
will go into more detail 
research efforts in this 
the use of computers. 


a series of seminars to acquaint computer system 
ith the status of "trusted"* ADP system developments 
of Defense and current planning for the integrity 
implementations of similar systems. This seminar 
both on the technical experiences of the DoD 
area and the implications of trusted systems on 


Following the first day of topics of general interest the seminar will divide 
into two parallel sessions. The technical session, intended for operating 
system developers and sophisticated computer science technical experts, 
will provide a detailed analysis of the Trusted Computing Base concept which 
is the emerging generalized basis upon which high integrity operating systems 
may be evaluated, followed by discussions by the principal designers of the 
major DoD trusted system developments relating their systems to the Trusted 
Computing Base Concept. The non-technica1 session will provide indepth 
discussion of policy issues as they apply to multilevel secure computer 
systems, an analysis of applications of such systems within the DoD and 
beyond, and a not-so-technica1 review of the Trusted Computing Base concepts. 

There will be extensive question and answer periods during both parallel 
sessions and audience interaction is encouraged. 

The Trusted Computing Base concept being introduced at this seminar is a 
first draft specification against which the integrity of computer systems 
may be evaluated. This draft specification is the result of much interaction 
within the DoD community and is being introduced here to obtain reactions 
from industry and other users. This draft specification is only a beginning 
and is expected to change significantly as a result of interactions with 
industry and government. 



*A "trusted" AOP system is one which employs sufficient hardware and software 
integrity measures to allow its use for simultaneously processing multiple 
levels of classified and/or sensitive information. 









ABOUT THE OoO COMPUTER SECURITY INITIATIVE 

The Department of Defense (DoD) Computer Security Initiative was established 
in 1978 by the Assistant Secretary of Defense for Communications, Command, 
and Control and Intelligence to achieve the widespread availability of "trusted" 
ADP systems for use within the DoD. Widespread availability implies the use 
of commercially developed trusted ADP systems whenever possible. Recent DoD 
research activities are demonstrating that trusted ADP systems can be developed 
and successfully employed in sensitive information handling environments. In 
addition to these demonstration systems, a technically sound and consistent 
evaluation procedure must be established for determining the environments for 
which a particular trusted system is uitable. 

The Computer Security Initiative is attempting to foster the development 
of trusted ADP systems through technology transfer efforts and to define 
reasonable ADP system evaluation procedures to be applied to both government 
and commercially developed trusted ADP systems. This seminar is the second 
in a series which constitute an essentia) element in the Initiative's 
Technology Transfer Program. 

The Institute for Computer Sciences and Technology, through its Computer 
Security and Risk Management Standards program, seeks new technology to 
satisfy federal ADP security requirements. The Institute then promulgates 
acceptable and cost effective technology in Federal Information Processing 
Standards and Guidelines. The Institute is pleased to assist the Department 
of Defense in transferring the interim results of its research being conducted 
under the Computer Security Initiative. 
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PROGRAM 


Second Seminar on the Department of Defense Computer Security Initiative 

National Bureau of Standards 
Gaithersburg, Maryland 

January 15, 1980 Red Auditorium 

9:30 am "The Impact of Computer Security in the Intelligence 
Community" 

Dr. John Koehler 

Deputy Director for Central Intelligence for 
Resource Management 

"The Impact of Computer Security in the Department 
of Defense" 

Dr. Irwin Lebow 

Chief Scientist 

Defense Communications Agency 

"The Impact of Computer Security in the Federal 
Government" 

Mr. James Burrows 

Director, Institute for Computer Science and 
Technology 

National Bureau of Standards 

BREAK 

"The Impact of Computer Security in the Private 
Sector" 

Mr. Ed Jacks 

General Motors Corporation 

"Status of the DoD Computer Security Initiative" 

Mr. Stephen T. Walker 

Chairman, DoD Computer Security Technical 
Consortium 


1:00 pm 


LUNCH 







January 15, 1980 
(Continued) 

2:00 pm 


4:30 pm 
January 16-17, 1980 

SESSION I 

January 16, 1980 

9:15 am 


1:00 pm 
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i 
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"Computer Security Impacts on Near Term Systems" 

Mr. Clark Welssman 

System Development Corpoiation 

"Computer Security Impacts on Future System 
Architectures" 

Mr. Ed Burke 
MITRE Corporation 

BREAK 

A "discussion" of what the computer manufacturers 
would like/should expect to hear from government 
users about trusted computer systems 

Dr. Theodore M.P. Lee 
UNIVAC Corporation 

Mr. James P. Anderson 
James P. Anderson Company 

ADJOURN 

TOO PARALLEL SESSIONS 

Gneral Session - Red Auditorium 


"Policy Issues Relating to Computer Security" 

Session Chairman: Robert Campbell 

Advanced Information Management, Inc. 

Mr. Cecil Phillips 

Chairman, Computer Security Subcommittee 
DCI Security Committee 

Mr, Eugene Epperly 

Counterintelligence & Security Policy Directorate 

Office of the Secretary of Defense 

Pentagon 

Mr. Robert Campbell 

Advanced Information Management, Inc. 

Mr. Philip R. Manuel 

Phillip R. Manuel and Associates 

Dr. Stockton Gaines 
RAND Corporation 

LUNCH 


X 





January 16, 1980 
(Continued) 

2:00 pm "User Requirements and Applications" 

Session Chairman: Dr. Stockton Gaines 
RAND Corporation 

Mr. Larry Bernosky 

WWMCCS System Engineering Office 

LtCol Cerny 

Federal Republic of Germany Air Force 
BREAK 

Dr. Tom Berson 
SYTEK Corporation 

Mr, Mervyn Stuckey 

U.S. Department of Housing and Urban Development 
4:00 pm ADJOURN 

January 17, 1980 
SESSION I 

9:15 am "User Requirements and Applications" (continued) 

Dr. Von Der Brueck 
IABG, Germany 

Mr. John Rehbehn 

Social Security Administration 

Mr. William Nugent 
Library of Congress 

Mr. Howard Crumb 

Federal Reserve Bank of New York 

BREAK 

"Trusted Computing Base Concepts" 

Mr. Peter Tasker 
MITRE Corporation 

1:00 pm LUNCH 

2:00 pm GENERAL DISCUSSION and WRAPUP 

Mr. Stephen T. Walker 





January 16-17 
SESSION II 


Green Auditorium 


Technical Session on Trusted Computing Base Design 

This session, intended for operating system developers and sophisticated 
computer science technical experts, will present the proposed Trusted 
Computing Base (TCB) concept, an internal protection mechanism for high- 
integrity, general-purpose computer systems. The most important issues 
and tradeoffs in the design of a TCB for a general-purpose minicomputer 
timesharing system will be discussed in detail. A technical background 
in computer science will be assumed. 

The first day will consist of a series of presentations by Mr. John P.L. 
Woodward and Ms. Grace H. Nibaldi from the MITRE Corporation. First, the 
concept of a Trusted Computing Base will be defined in detail, and the two 
categories of TCB functions, software interface functions and user interface 
functions will be discussed. Then each of these functional areas will be 
discussed individually, with examples drawn from past and present TCB 
developments. 

At the end of the presentations, members of the audience will be asked to 
identify design decisions they have faced in an operating system design or 
similar effort to determine how these decisions relate to the choices that 
must be made in TCB design. The audience will be encouraged to write their 
thoughts down for possible discussion on the. second day. 

The second day will consist of a panel discussion by the developers of 
the following trusted operation systems: 

Kernelized Secure Operating System (KSOS-ll) 

Dr. McCauley, Ford Aerospace and Computer Corporation 

Kernelized Secure Operating System (KSQS-6) 

Mr. Bonneau, Honeywell Corporation 

UCLA Data Secure UNIX 

Dr. Popek, University of California at Los Angeles 

Kernel ized VM-370 (KVM) 

Mr. Schaefer, System Development Corporation 

The developers will describe their TCB's and discuss the design issues they 
encountered and the tradeoffs they made in their designs. Following this, a 
question, answer, and general discussion session will be held. 

Extensive audience comments and questions are expected and encouraged. 










Welcome and Opening Words 


Stephen T. Walker 

Chairman, DoD Computer Security 
Technical Consortium 


Welcome to NBS and the Second Seminar on the DoD Computer Security 
Initiative. 

My name is Stephen T. Walker and I am Chairman of the Computer 
Security Technical Consortium which is responsible for the activities of 
the Initiative. 

The goal of the Initiative is to achieve widespread availability 
of the trusted computer systems. 

As your handout indicates, we define a "trusted" system as one with 
sufficient hardware and software integrity measures to allow simultaneous 
processing of multiple levels of sensitive information. 

That is a rather complicated definition that simply means we can rely 
on the computer itself to protect information from unauthorized use or 
modification or even more simply stated to make the computer work the way 
we want it to. 

By widespread we meant generally available to a large customer base, 
not special purpose. 

This is a complex problem, a subset of the overall computer security 
problem (which includes physical, administration, personnel security) 
one which hasn't received much attention until recently, largely because 
it was felt by many to be too difficult to solve. 

Trusted computers are the subject of this seminar but before we go any 
further, it is important to note that a solution to this problem does not 
diminish the need for physical and administration security measures though 
it may in some cases ease these measures for remote users at least. 

Many computer users especially those outside of the Department of 
Defense have said (and undoubtedly will continue to say) our physical 
security measures are so lax that we couldn't use a trusted computer if we 
had one. Many have used this situation as an excuse not to worry about the 
integrity inside their computers. 

Indeed, many facilities do not have reasonable physical and administrative 
measures today. But there is a very important point here which must be 
understood. If a computer user today wishes to take appropriate physical and 
administrative security measures to protect his system (as many already do), 
the technology needed to do this is readily available and well understood. 

There are plenty of places to go for advice and help. 


A-l 








If, however, a user wishes to install a computer in which he does 
not have to treat all information and all users at the same sensitivity 
level, he doesn't have many options today. We are trying to change that 
situation. 

I maintain that any computer facility processing information that is 
of any value at all, be it a large central system or a network of small 
systems or something in between, will eventually come up against the need 
for integrity within the computer system itself. We in the Department of 
Defense have been hampered by the lack of internal integrity within 
computers for some time, as many of the upcoming speakers will testify. 

But others, dealing with sensitive information outside of the national 
security classified world have also encountered this problem, and many 
of them will speak in the next three days. 

One major premise, then, of the computer security initiative is that 
there is a widespread and growing need for computers with high levels of 
integrity within the Department cf Defense, within the Federal Government, 
and within the private sector. The first major objective of the seminar 
is to make that widespread need very clear. 

We hope this portion of the seminar will motivate the computer 
manufacturers to get involved in building high integrity systems to 
satisfy the full spectrum of needs of their customer base. 

The solution to this system integrity problem will be difficult 
and will take time to accomplish on a broad scale. We in the DoD have 
been working on technical solutions for some years and we believe that 
some early solutions to the problem are now becoming available. 

The techniques needed to develop a trusted computer system involve 
a strict adherence to good system development practices plus a strong dose 
of formal specification and verification both of the design and the 
implementation of a system. The stronger the successful dose of this 
specification and verification process the greater the confidence that can 
be placed on the system. These techniques are derived from and closely 
linked to the system development techniques evolving in the major computer 
science research centers around the country. We are not looking for radical 
changes in the state-of-the-art in system development. Unfortunately, most 
systems currently in development or being marketed by the manufacturers do 
not represent anything close to the state-of-the-art in system development 
and therefore a major shift will be required by many of the manufacturers, 
in effect catching up with the state-of-the-art, before trusted computers 
will become generally available. 

A second major premise of the computer security initiative then is 
that the technology needed to develop trusted computer systems exists today. 

The second major objective of this seminar is to describe in detail 
the experiences we have had in developing these systems. We hope this 
portion of the seminar will make clear what we feel are important steps 
needed to build high integrity systems and therefore make it easier for 
the manufacturers to develop such systems. 
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In reviewing the preregistered attendee list, I was again impressed, 
as with the first seminar which we held last July, with the broad spectrum 
of interests represented in the audience. I will give you a breakdown 
of who you are a little later, but I was reminded, as I thought of all the 
different perspectives here, of the familiar story which bears repeating, 
of the blind men who encountered an elephant for the first time and were 
asked to describe what an elephant is, based on their limited experiences. 

One, who encountered the elephant's leg insisted that an elephant is a tree 
because it is round and tall and had a rough skin. Another who encountered 
the flank insisted that an elephant must be a wall because it was tall 
and wide and flat. A third, who ran into the tail, insisted it must be 
a rope with a tassel on the end, while the fourth, feeling the trunk, was 
certain that an elephant must be a hose with the two holes in the end. 

We've all heard this story before but I feel it is particularly appropriate 
in this context because of the wide variety of backgrounds which we all 
represent. It is important as we begin these three days that each one of 
us realize that whatever our own perspective on the computer security 
problem, we are limited in our understanding by the experiences we have had. 

As we listen to the speakers, we should try hard to understand the perspective 
of the speaker and in that way broaden our understanding of the total 
computer security problem. 

As indicated in Dr. Dineen’s keynote address at the July Seminar, 
printed in your program, the Department of Defense views the problem 
of achieving a high degree of integrity in computer systems as very important 
to our future information handling needs. The DoD has in the past and will 
continue in the future to build special purpose systems to satisfy specific 
vital DoD needs, but our need for trusted computer systems goes well beyond 
our ability to build specialized DoD systems. Furthermore many of the reasons 
we need trusted systems, for protecting sensitive information be it classified 
data, personnel files, financial or logistic records, are not at all unlike 
the needs of the rest of the government and the private sector. We feel 
the best way to solve our needs in this area is to encourage the computer 
manufacturers to develop trusted systems so that all of us — DoD, 
government and private sector users — can make full and effective use of 
the results. In this way all our needs can be satisfied in the most general 
manner for the least expense to any of us. 

Just getting the manufacturers to develop trusted systems isn't quite 
enough though. We will talk later in the seminar about the evolution of 
a process for evaluating the integrity of computer systems to determine 
the environments and applications for which they are suitable. What we will 
have to say about this is necessarily preliminary and not formalized in any 
sense. We realize that having some form of evaluation process readily 
available is essential to the acceptability of trusted computer systems and I 
can assure you we are hard at work trying to establish the proper and consistent 
procedures for evaluating computer systems in a way that will benefit all 
interested parties. 

With all this as background then, let us begin. 
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"The Impact of Computer Security in 
the Intelligence Community" 

Dr. John Koehler 

Deputy Director for Central Intelligence 
for Resource Management 

Outline of talk given at DoD Computer Security Conference - 
January 15 , 1980 . 


1. Introductory Remarks: 

a. Greetings from DC1 

b. Congratulations and thanks to sponsors - DoD and NBS 

c. DCI staff and all elements of the Intelligence Community 
cooperating with DoD Computer Security Initiative because 
of its importance to future progress in intelligence 

2. The fundamental importance of computers 

a. The business of intelligence is information processing 

b. Time critical nature of intelligence information 

c. Time constraints, especially in I&W and for support to 
military operations have become progressively narrower 

d. Increasing demands on the Intelligence Community are 
apparent 

* The international environment is increasingly complex. 

We have spent great efforts to support treaty negotiations 
and monitoring; concurrently, the conflict and threat of 
conflict in peripheral areas require greater attention. 

* As with Defense, real resources going to the Intelligence 
Community have generally declined over the last decade. 

* Faced with this situation, there would have been no way 
in which the Intelligence Community could have continued 
to have fulfilled the expanding requirements levied upon 
it without a heavy reliance on increasingly complex and 
competent data processing and communications systems. 


B-l 











3. Computers, because of the historical pattern of their development, 
while helping to solve the Intelligence Community's problems 

have posed substantial new problems of their own— 

* The Intelligence Community always faces a dilemma: because 
our sources are fragile, the information needs to be 
closely held, locked up, protected. But the purpose of 
gathering and producing intelligence is to help make 
better decisions. That requires data to be processed 
quickly and information disseminated quickly and broadly. 

* The historical pattern of development of computer systems 
has made choosing among the two objectives of security and 
dissemination especially difficult. 

* The Von Neumann concept of the digital computer, implementing 
the computer's internal executive functions through programs 
executed in the same manner as applications programs, 

has made the present day computer highly vulnerable to 
sophisticated attack. 

* The relatively unstructured development of today's extremely 
large and complex operating systems has further exacerbated 
the problem. 

* The vulnerability which this has led to in today's computer 
systems, coupled with the concentration in one place of 
large masses of highly sensitive classified information, 
have posed problems with which it has proved extremely 
difficult to cope and which steadily increase in magnitude. 

4. This is not to say that the Intelligence Community's present day 
information processing and handling systems pose an undue security 
hazard. 

* Faced with a lack of trusted software with which to implement 
security controls, we have had to rely heavily on physical 
security for systems to which all access is denied except 

to those cleared to the highest level of classification of 
any of the material present in any particular system. 

* To enforce such a security policy has, however, required 
considerable expensive duplication of resources, has placed 
a severe strain on security clearance procedures, and has 
restricted access to information more than we desire. 

* As we strive to improve the efficiency with which the Intelligence 
Community executes its mission by taking advantage of the 
concept of distributed data bases and interactive real-time 
access to the expanding volumes of information which new 
techniques of internetting and high speed bulk transfer of 

data make possible, we can foresee the time when present 
solutions to the security problem will no longer be adequate. 
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5. For the foregoing reasons, the DCI and his staff elements immediately 
concerned with the problem have taken an active part in supporting 
and encouraging the DoD Computer Security Initiative Program. 

6. As Dr. Dineen noted in his keynote address to the first of these 
seminars, "The DoD cannot afford, just for the sake of having 
trusted computer systems, to develop its own general purpose 
hardware and software systems." 

* If the DoD, with all its resources cannot afford to do so, 
it goes without saying that the Intelligence Community 
cannot afford to do so either. 

* In the infancy of computer technology, because of the 
unavailability of commercial systems and the importance 
of the capabilities of the electronic computer to the 
Intelligence business, the Intelligence Community did just 
that. 

* Now, however, the magnitude, complexity and cost of today's 
generalized systems and their widespread availability in 
the commercial market militates against the development 

by the Intelligence Community of any but the most specialized 
intelligence processing systems. 

* Therefore, we, along with the DoD, must rely on and 
encourage the development of trusted systems by the industry. 

* To the extent that industry does meet the challenge of the 
security problem and produce systems which are demonstrably 
more secure, the Intelligence Community will provide a 
ready market for such products. 

7. We recognize that as significant a portion of the intelligence and 
defense budgets as data processing and telecommunications are, the 
size of this market alone cannot totally justify the expenditure 
of the resources required to develop and market trusted software 
systems. 

* However, we are convinced that the problems of computer 
security are in no way limited to the Intelligence 
Community or the Department of Defense alone. They happen 
to be more critical in our areas of concern and therefore 
we are the most cognizant of them. 
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* As computers assume more and more decision making functions 
and as more and more financial transactions are initiated 
and executed by computers without human intervention, 
making obsolete traditional control mechanisms and audit 
functions, the problems of computer security will gain 
greater and greater Importance and attention in government 
in all its functions and at all levels, national,' state, 
and local. Nor will business, particularly the financial 
community, lag far behind this growing trend. 


8. Thus, it is to the great mutual self-interest of ourselves and 
the data processing industry that we exert the utmost effort to 
work together to build on progress which has been made in this 
area by the DoD Computer Security initiative. 


* Just as the Intelligence Community cooperated with industry 
and other elements of the Federal government in developing 
the Data Encryption Standard in the field of communications 
security, the Intelligence Community encourages and stands 
ready to assist in any way that it can in the development 
of improved computer security in the commercial field. 
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"THE IMPACT OF COMPUTER SECURITY IN THE DEPARTMENT 
OF DEFENSE" 

OUTLINE 

• THE DOD COMPUTER SECURITY CONTEXT 

•• NATIONAL LEVEL COMMAND AND CONTROL 
• • OCA RESPONSIBILITIES 

• DEFINITION OF THE COMPUTER SECURITY PROBLEM 

• OPERATIONAL LIMITATIONS RESULTING FROM 
CURRENT APPROACHES TO SECURITY 

• EVOLUTION OF WWMCCS COMPUTER CONNECTIVITY 

• LESSONS LEARNED 

• CONCLUSIONS 

Dr. Irwin Lebow 
Chief Scientist 
Defense Communications Agency 


MAJOR DCA RESPONSIBILITIES 


SUBJECT 


DCA RESPONSIBILITY 


• WORLD WIOE MILITARY COMMAND ft 
CONTROL SYSTEM IWWMCCSI 


ARCHITECTURE Et SYSTEMS 
ENGINEERING 


• • NATIONAL MILITARY COMMAND SYSTEM 

INMCSI 

• • STANDARD AOP SYSTEMS 


• • MINIMUM ESSENTIAL EMERGENCY 
COMMUNICATIONS NETWORK IMEECNI 


DETAILED SYSTEMS ENGINEERING 
AND ADP SUPPORT 

ARCHITECTURE, SYSTEMS ENGI 
NEERING b COMMON SUPPORT 

SYSTEMS ENGINEERING 


• DEFENSE COMMUNICATIONS SYSTEM MANAGEMENT, ARCHITECTURE, 

SYSTEMS ENGINEERING 


• MILITARY SATELLITE COMMUNICATIONS SYSTEMS 


ARCHITECTURE 








WWMCCS STANDARD ADP SYSTEMS 


• CURRENT SYSTEM 

35 SITES (CONUS, PACIFIC, EUROPE! 

STANDARD HARDWARE 
H6000 MAINFRAME 

ON355 COMMUNICATIONS CONTROLLER 
VISUAL INFO, PROJECTION TERMINALS 

STANDARD SOFTWARE 

GCOS SYSTEM SOFTWARE 
CERTAIN APPLICATIONS SOFTWARE 

NETWORKING WWMCCS COMPUTERS 

CURRENTLY VIA DEDICATED WWMCCS INTERCOMPUTER 
NETWORK (WIN! 

POST 1981 VIA COMMON USER AUTOOIN II 

• DEFINITION OF ALTERNATIVES FOR MAJOR UPGRADE 

NOW UNDERWAY 



EVOLUTION OF DCS DATA SYSTEM 


• CURRENTLY AUTODIN I 

• 1980 - 1985 AUTOOIN l/AUTODIN II 

• • AUTODIN II PACKET SWITCHING BACKBONE 
•• AUTODIN I MESSAGE SERVICE "HOSTS'’ 

• POST 1985 AUTOOIN II 

• • AUTODIN I "HOSTS" PHASED OUT 

• • MESSAGE SERVICE (AND OTHER SERVICES) 

PROVIDED ELSEWHERE 
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OPPOSING FORCES il\l 
THE EVOLUTION OF THE DCS 

O DESIRE FOR MORE EFFECTIVE, EXTENSIVE 
INFORMATION SHARING AND EXCHANGE 

O FEAR OF COMPROMISE OF SENSITIVE DATA 


THE COMPUTER SECURITY PROBLEM 


TO PROTECT USER INFORMATION 
ON SHARED COMPUTER SYSTEMS 









PROTECT USER INFORMATION 


• PREVENT DATA COMPROMISE 
O PREVENT DENIAL OF SERVICE 

• GUARANTEE DATA INTEGRITY 


“SHARED COMPUTER SYSTEMS" 

O HOSTS 

O HOST FRONT END DEVICES 
O TEXT MESSAGE HANDLING SYSTEMS 
O TERMINAL ACCESS CONTROLLERS 
O SWITCHING NODES 
• GATEWAYS ETC 
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ASPECTS OF THE 
COMPUTER SECURITY PROBLEM 


• AUTHENTICATION PROBLEM: 

PREVENTING PENETRATION BY UNAUTHORIZED USERS 

• MULTILEVEL SECURITY PROBLEM: 

PREVENTING MISUSE BY AUTHORIZED USERS 


APPROACHES TO AUTHENTICATION 


IDENTIFY A USER BY 


• WHAT HE IS 

• WHAT HE KNOWS 

• WHAT HE HAS 







APPROACHES TO MULTILEVEL SECURITY 


• LOGICALLY SEPARATE USERS: KERNEL TECHNOLOGY 

• DISGUISE DATA: END-TO-END ENCRYPTION 


WHY IS COMPUTER SECURITY 
A PROBLEM? 

o SENSITIVE/CLASSIFIED DATA STORED ONLINE 

• MULTILEVEL SECURITY IS A DIFFICULT TECHNICAL 
PROBLEM 

• SECURITY DEMANDS ARE INCREASING 


9 CURRENT APPROACHES ARE EXPENSIVE, 
INADEQUATE 











CURRENT APPROACHES STRESS 
PHYSICAL CONTROL 

e PHYSICAL CONTROL OF ACCESS AREAS 
O DEDICATED (REPLICATED) COMPUTER SYSTEMS 
o PERIODS PROCESSING 
o SYSTEM HIGH CLEARANCES 


SECURITY PROBLEM AT HQ 
FORCES COMMAND (FORSCOM) 


H6000 


1 ON 355 1 

MUST SUPPORT CONNECTION TO 



JCS, USREOCOM, DA. LANTCOM_ 


>40 SECRET TERMINALS 
THROUGHOUT CONUS 


WWMCCS COMPUTERS OPERATING 
AT TOP SECRET 









HIHbUUIVI bULUliuiM: urmvMuc aumc 
TERMINALS, PERIODS PROCESS 



SECRET TERMINALS WHICH CANNOT i ] TERMINALS UPGRADED TOP SECRET 

BE CLEARED TO TOP SECRET ( i TO TOP SECRET WWMCCS 


COMPUTERS 


TIME 


DRAWBACKS OF FORSCOM SOLUTION 

o COST TO UPGRADE SECRET FACILITIES TO TOP SECRET 

• • EXTENSIVE PERSONNEL BACKGROUND INVESTIGATIONS 

• • MORE CUMBERSOME ADMINISTRATIVE, OPERATING 

PROCEDURES 

• OPERATIONAL LIMITATIONS 

• • NO SERVICE DURING COLOR CHANGES 

• • INTER CONNECTIVITY RESTRICTED TO SPECIFIC PERIODS 
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SECURITY PROBLEM AT MILITARY 
AIRLIFT COMMAND (MAC) 


H600Q 


} DW 355 1 

MUST SUPPORT CONNECTION TO 



TERMINALS 

SUPPORTING 

UNCLASSIFIED 

MISSIONS 



TERMINALS 
SUPPORTING 
TOP SECRET 
MISSIONS 


JCS, USREDCOM. DA, . . . 


WWMCCS 
COMPUTERS 
OPERATING 
AT TOP SECRET 


MAC SOLUTION: REPLICATE SYSTEMS 

UNCLA S SIFIED SYSTEM TOP SECRET SYSTEM 

H6000 

ITS) 


H6000 

(U) 

















DRAWBACKS OF MAC SOLUTION 


• COST TO REPLICATE MAINFRAMES 

• • REPLICATED PURCHASE, MAINTENANCE COST 

• • REPLICATED OPERATING EXPENSES 

• OPERATIONAL LIMITATIONS 

•• TOP SECRET SYSTEM MUST ACCESS 

UNCLASSIFIED DATA BASES MANUALLY 
PROCEDURE INCONVENIENT. DATA NOT 
CURRENT 

• • COMPUTER RESOURCE CANNOT BE ASSIGNED 

DYNAMICALLY 


EVOLUTION OF WWMCCS 
COMPUTER CONNECTIVITY 


ISOLATE!) SITES 


ISOLATED SITES 
WITH REMOTE 
TERMINALS 


SITES CONNECTED 
BY AUTODIN I \ 


SITES CONNECTED 
BY AUTODIN II 


SITES CONNECTED 
BY WIN 


TIME 

SECURITY RISK 
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COMPUTER SECURITY 
RISK IS A FUNCTION OF: 


• COMPUTING ENVIRONMENT 

(SPAN OF PHYSICAL/ADMINISTRATIVE CONTROL) 


• DEGREE OF USER FREEDOM 

(SPAN OF LOGICAL CONTROL) 


TWO DIMENSIONS OF SECURITY RISK 


HIGH 


DEGREE OF 

USER 

FREEDOM 


INCREASING SECURITY RISK 


X 



SITES CONNECTED 
BY WIN 


X 

SITES CONNECTED BY 

X X AUTODIN I 

ISOLATED ISOLATED SITES 

SITES WITH REMOTE TERMINALS 


LOW 


INCREASING SECURITY RISK 


LOW HIGH 

DIFFICULTY OF PHYSICAL/ADMINISTRATIVE CONTROL 
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ISOLATED WWMCCS SITES 
WITH LOCAL TERMINALS 


O "SHARING" AMONG LOCAL USERS 
O PHYSICAL/ADMINISTRATIVE CONTROL COMPLETE 
Q REPLICATED SYSTEMS 
G SYSTEM HIGH CLEARANCES 



ISOLATED WWMCCS SITES 
WITH REMOTE TERMINALS 

Q "SHARING" AMONG LOCAL USERS. REMOTE USERS ON 
DEDICATED LINES 

O LINK ENCRYPTION ON COMM LINES 
G PHYSICAL/ADMINISTRATIVE CONTROL DISPERSED 
Q REPLICATED SYSTEMS 
Q SYSTEM HIGH CLEARANCES 
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AUTODIN I 


• INITIAL OPERATION 1963 

O MESSAGE SWITCHING STORE-AND-FORWARD NETWORK 

• • 9 U. S.. 9 OVERSEAS SWITCHES 

• • <_ 9600 BAUD TRUNKS 

• 2250 SUBSCRIBER TERMINATIONS 

• •MILITARY AGENCIES 

• •INTELLIGENCE AGENCIES 

• •CIVILIAN AGENCIES 

• •NO DIAL-UP ACCESS 

• PROVIDES WRITTEN RECORD COMMUNICATIONS SERVICE 

• •BATCH-STYLE SERVICE 

• •FORMAL MESSAGE FORMATS 


U.S. AUTODIM I 







AUTODIN i SECURITY 


• MULTILEVEL SECURE BY FIAT 

•• PHYSICAL SEPARATION OF USERS (R/Y) 

•• REDUNDANT SOFTWARE CHECKS 
•• PEOPLE IN LOOP 

•• PHYSICAL/ADMINISTRATIVE CONTROL OF 
SWITCHES 

• • EXTENSIVE MESSAGE JOURNALLING 

• • LINK ENCRYPTION 

• • RESTRICTED USER/NETWORK INTERFACE, i.e., 

NO USER PROGRAMMING IN SWITCH 


WWMCCS COMPUTER INTERCONNECTION 
VIA AUTODIN I 


• PHYSICAL/ADMINISTRATIVE CONTROL GEOGRAPHICALLY 
DISPERSED, INCOMPLETE 

• • WWMCCS SITES GEOGRAPHICALLY DISPERSED 

• • NON-WWMCCS SUBSCRIBERS BEYOND WWMCCS 

CONTROL 

• NO DATA SHARING IN COMPUTER SENSE VIA AUTODIN I 

• • RECORD TRAFFIC PASSED AMONG WWMCCS SITES. 

OTHER SUBSCRIBERS 

•• NO INTERACTIVE USER PROGRAMMING VIA 
AUTODIN I 









• COMUSKOREA 










WIN SECURITY 


NOT MULTILEVEL SECURE 

SYSTEM HIGH (TSI FOR ALL HOSTS 
PHYSICAL/ADMINISTRATIVE CONTROL OF ALL SWITCHES, 
ACCESS AREAS 
LINK ENCRYPTION 


WWMCCS INTERCONNECTION VIA WIN 


• PHYSICAL/ADMINISTRATIVE CONTROL GEOGRAPHICALLY 
DISPERSED. COMPLETE 

• •WWMCCS SITES GEOGRAPHICALLY DISPERSED 
••SUBNET DEDICATED TO WWMCCS COMMUNITY 
••ACCESS AREAS CONTROLLED (NO DIAL-UP ACCESSI 

• ALL INTERCONNECTED SITES OPERATE SYSTEM HIGH 
AT TS 

• DATA SHARING AMONG INTERCONNECTED SITES 
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AUTODIN II 


• INITIAL OPERATION 1980 

• PACKET SWITCHING NETWORK 

• • 4 PSN * INITIALLY, EXPANDABLE TO B 

• • PSN's ARE MULTIPLE POP U/70's 

• • 56 KB/S TRUNKS 

• COMMON USER 000 NETWORK 

• • MILITARY AGENCIES 

• • INTELLIGENCE AGENCIES 

• • 000 RELATED ACTIVITIES 

• • DIAL-UP ACCESS PROVIDED 

• PROVIDES COMPUTER-TO-COMPUTER INFORMATION 

EXCHANGE 

• • INTERACTIVE SERVICE 

• • TCP. THP PROTOCOLS; LAYERED FOR EVOLUTIONARY GROWTH 


AUTODIN II SECURITY 


MULTILEVEL SECURE 

• KERNEL TECHNOLOGY IN PSN'S 

FORMAL VERIFICATION OF TOP LEVEL 
SPECIFICATION 

FACILITATED BY RESTRICTED USER/NETWORK 
INTERFACE, I.E., NO USER PROGRAMMING IN PSN’S 

• PHYSICAL/ADMINSTRATIVE CONTROL OF ALL PSN'S 


• LINK ENCRYPTION 






WWIVlUUb IIMI tKUJIVIVtM IUIM 

VIA AUTODIM II 


• PHYSICAL/ADMINISTRATIVE CONTROL GEOGRAPHICALLY 
DISPERSED. INCOMPLETE 

• • WWMCCS SITES GEOGRAPHICALLY DISPERSED 


• • NON-WWMCCS SUBSCRIBERS BEYOND WWMCCS 

CONTROL 

• • DIAL-UP ACCESS PROVIDED 


• AUTODIN II PROVIDES MLS DATA EXCHANGE - SITES 

NOT MLS 

• DATA SHARING AMONG WWMCCS SITES. OTHER 

SUBSCRIBERS 


LESSONS LEARNED 


NO.I OUR APPLICATIONS "EYES" ARE BIGGER THAN OUR SECURITY 
TECHNOLOGY "STOMACHS" 

O ENORMOUS ADVANCES IN COMPUTER HARDWARE HAVE 
OCCURRED 

O MODEST BUT SIGNIFICANT ADVANCES IN COMPUTER 
SOFTWARE HAVE OCCURRED 

• THESE ADVANCES SPAWNED REQUIREMENTS FOR 

SOPHISTICATED APPLICATIONS 

• THESE APPLICATIONS HAVE LED TO GREATER SECURITY 

BURDENS 

• SECURITY TECHNOLOGY HAS LAGGED 








TECHNOLOGY 

ADVANCES 


HAROWARE 



LESSONS LEARNED 


NO. 2. SOFTWARE. NOT HARDWARE, DOMINATES LIFE 
CYCLE COST 

• SOFTWARE DEVELOPMENT COST 

(QUICK DESIGN. QUICK CODING. TEST, FIX, TEST, FIX. . . . ) 

• SOFTWARE MAINTENANCE COST 

(SOFTWARE CHANGE. TEST, FIX, TEST. FIX_) 

• SOFTWARE DOCUMENTATION COST 

(INCOMPLETE, INACCURATE, OUT-OF-DATE SYSTEM 
DESCRIPTIONS) 

• SOFTWARE CONVERSION COST 

(DATA AND PROCEDURE) 
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LESSONS LEARNED 


NO. 3. SECURE SOFTWARE MAY BE MORE EXPENSIVE STILL 

• INCREASED DESIGN COST 

• ADDITIONAL COST OF VERIFICATION AND CERTIFICATION 

• INCREASED MAINTENANCE COST FOR RE-VERIFICATION. 
RE-CERTIFICATION 

• PERFORMANCE PENALTY OF UNKNOWN MAGNITUDE 


LESSONS LEARNED 

NO. 4. SOFTWARE INVESTMENT MUST BE PRESERVED 
OVER CHANGES IN HARDWARE. REQUIREMENTS 

• A. MINIMIZE HARDWARE DEPENDENCIES 

• • SPECIFY SYSTEM BY FUNCTION. NOT HARDWARE 

CHARACTERISTICS 

• • MINIMIZE ASSUMPTIONS MADE IN SOFTWARE ABOUT 

HARDWARE CHARACTERISTICS 

• • EVALUATE IMPACT BEFORE OPTIMIZING SOFTWARE FOR 

PARTICULAR HARDWARE CONFIGURATION 

• • USE UBIQUITOUS HIGHER ORDER LANGUAGE(S) 
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LESSONS LEARNED 


NO. 4. SOFTWARE INVESTMENT MUST BE PRESERVED OVER 
CHANGES IN HARDWARE, REQUIREMENTS 


• B. SIMPLIFY SOFTWARE 


••PROGRAM FOR CLARITY, EASY MAINTENANCE, EASY TRANSPORT¬ 
ABILITY (NOT DEVELOPMENT SPEED, EXECUTION SPEED. ETC.) 

••SUBSTITUTE HARDWARE FOR SOFTWARE COMPLEXITY WHERE 
FEASIBLE (BUY MORE MEMORY, FASTER PROCESSOR. ETC.) 

••AUGMENT WITH OTHER APPROACHES WHICH LIMIT THE 

AMOUNT OF SECURITY RELATED SOFTWARE (e. g„ ENCRYPTION) 


LESSONS LEADED 

NO. 4. SOFTWARE INVESTMENT MUST BE PRESERVED OVER 
CHANGES IN HARDWARE, REQUIREMENTS 

OC. RATIONALIZE, CONTROL SOFTWARE DEVELOPMENT PROCESS 

• • TOP-DOWN DESIGN. IMPLEMENTATION 

• • USE SOFTWARE DEVELOPMENT TOOLS 


• • EMPHASIZE CLEAR, COMPLETE, CURRENT DOCUMENTATION 

















LESSONS LEARNED 


1 


1 

, j 

1 

i 

1 

MO. 5. CAPITALIZE ON COMMERCIAL HARDWARE DEVELOPMENTS 

• USE OFF-THE-SHELF HARDWARE WHENEVER FEASIBLE 
(NOT CUSTOM DESIGNED, SPECIAL PURPOSE GEAR) 

• EMPHASIZE (AND PAY FOR) MORE TRANSPORTABLE SOFTWARE 


CONCLUSIONS 


• DEMAND IS INCREASING FOR MORE ADP SUPPORT FOR THE 
WWMCCS VIA NETWORKING 

9 MULTILEVEL SECURITY CANNOT BE RETROFITTED INTO THE 
CURRENT GENERATION OF WWMCCS ADP 

O PROSPECTS FOR THE NEXT GENERATION OF WWMCCS ADP 
ARE EXCITING, BUT SECURITY IS APT TO BE THE MAJOR 
TECHNOLOGICAL LIMITATION 
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SPECIFIC WWMCCS TECHNICAL OBJECTIVES 

• MORE RELIABLE AUTHENTICATION METHODS 

• MULTILEVEL SECURITY (FOR HOSTS, AMHS_) 

• DISCRETIONARY (NEED TO KNOW) SECURITY AT EFFECTIVE 
LEVEL OF GRANULARITY 

• PROTECTION AGAINST DENIAL OF SERVICE 

• END-TO-END NETWORK SECURITY 

• ALL THE ABOVE AT MODEST COST 
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Impact of Computer Security in the Federal Government 


J. H. Burrows 
Director 

Institute for Computer Sciences and Technology 
National Bureau of Standards 


Introduction 


As a co-sponsor and host of this Seminar on Computer Security, I would 
like to welcome you to the National Bureau of Standards. As Steve said, 
before coming to the Bureau as Director of its Institute for Computer Sciences 
and Technology in May of last year, I spent seven years in the Department of 
Defense working in many areas in which computers played an important, if not 
crucial role. While there, I became more interested in the computer security 
problem in general and the Computer Security Initiative in Trusted Computer 
Systems in particular. I am very pleased that I am able to participate in 
this seminar, both because of my personal experience and interest, but also 
because of the official role that we at NBS are playing in computer security. 

I want to spend the next few minutes telling you about our perception 
of the need for computer security within the Federal Government but not 
necessarily within the l . tment of Defense. We have just heard two 
excellent presentations o the need for such security within the intelligence 
and communications arms of DoD. In the next two and one-half days, you will 
hear a great deal on the technology of computer security and also specific 
requirements for this security. Rather than dwelling on the technology or 
repeating the general platitudes of computer security, I want to walk through 
a case example which we at NBS find very intriguing, not only because of its 
obvious need for the technology to be discussed at this seminar, but also 
because of the multitude of reasons why this technology may have difficulty 
being accepted. Before I begin that walk, I would like to outline our 
perspective of a trusted system. 

According to the brochure announcing this seminar, a "trusted" ADP 
system is one which employs sufficient hardware and software integrity measures 
to allow its use for simultaneously processing multiple levels of classified 
and/or sensitive information. This personification of a machine requires some 
evaluation. A "trustee" in a prison is "trusted" not to break out of prison. 

I hope this is not the proper analogy to a trusted computer. A "trustee" in 
a real estate loan transaction is a "trusted" third party who knows and 
explicitly carries out the policies and procedures that were specified in the 
transaction agreement between the two primary parties. The trustee is 
required by law to automatically carry out these procedures when triggered by 
a specific event. I believe this is the analogy we seek when personifying 
a "trusted" computer. The suppliers of data and the users of the data are 
the two primary parties in our example. The computer is the third party 
"trustee." It must, however, be programmed with the policies and procedures 
of protection and control desired by the primary parties. My view is that the 
Department of Defense has a "leg up" on the rest of the Federal Government 
because of the written existence of these policies and procedures regarding 
classified information. The technology of the DoD trusted system will be 
applicable but the first requirement for computer security outside DoD is for 
the development of a new set of policies and procedures to be implemented in 
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the trusted system. This is no trivial task. In the extremely simple area of 
classified information (not involving money or property) and a single unified 
goal, DoD struggled for over five years to come up with their written policy 
and have yet to close on the parameters of a certification policy acceptable 
to all of DoD. 

Case Example of Computer Security Requirements 

I am sure you all are aware of the existence of the Environmental Protection 
Agency. I am not sure if you know of their very broad role as dictated by 
Congress and EPA's establishing Presidential order. 1 have chosen to use EPA as 
an example of the need for computer security in the Federal Covernment and to 
outline the multitude of conflicting data processing security requirements. 

EPA has informally requested the assistance of NBS in specifying reasonable 
security provisions which can best satisfy these requirements. For this reason, 

I am able to outline some of the problems as seen by EPA in this area. 

EPA was established by Presidential Order in 1970. At that time, 15 
environmental control programs were unified in a single regulatory agency. EPA 
is charged with mounting an integrated, coordinated attack on the environmental 
problems of air and water pollution, solid waste management, pesticides, 
radiation, noise and toxic substances. Since its establishment. Congress has 
added to this list of responsibilities. EPA is specifically required to set 
standards for the limits of pollution, enforce compliance with these limits and 
monitor the progress of reducing pollution even if below the established limits. 

Organizationally, EPA consists of six primary offices reporting to an 
Agency Administrator. Best known are the Office of Water and Hazardous Materials, 
Office of Air and Waste Management, and the Office of Toxic Substances. 

Thirteen different major Congressional Acts govern the actions of just these 
three offices. Some examples of their regulatory responsibilities will serve 
to demonstrate their need for complete and accurate data and trusted data 
processing capabilities. 

o EPA is required to conduct research on all aspects of water pollution and 
control dumping of all pollutants (including radioactive waste) into all 
navigable waters. Any U.S. citizen has the right to take legal action 
against a water polluter. 

o EPA is required to set safe drinking water regulations and enforce those 
regulations if each state does not or cannot. Again, any citizen has 
the expressed right to bring civil suit against any public water system 
or any Federal agency (including EPA) in violation. 

o EPA is required to set air quality standards for all air pollutants and 
assisting states in meeting those standards. Citizens are specifically 
authorized to take necessary legal actions against private or Government 
officials failing to meet provisions of the Clean Act. 

o EPA is required to develop programs for testing, monitoring and regulating 
chemical substances and pesticides. Manufacturers must register with EPA 
all insecticides, herbicides and fungicides intended for sale in the U.S. 
and notify EPA at least 90 days before the manufacture of any chemical 
intended for commercial purposes. 









o EPA is required to collect, maintain, protect and process accurate and 
complete data in support of these activities. 

EPA estimates that 35 billion characters of data will be maintained in the 
data bases of its two computer centers - one in North Carolina and one in Washington 
in 1980 with a fivefold increase expected in 1990. A completely new computer 
facility is being designed to support all the activities of EPA. Presently 
intended for first operation in the mid 80's, the system will be designed according 
to the goals of 0MB Circular A-109 to be useful and cost-effective for a life cycle 
of 10-15 years. 

Some interesting security, integrity and privacy issues which EPA must 
address include: 

(1) Manufacturers must submit extensive reports to EPA on a regular basis. 

EPA plans to allow the manufacturers to supply the data in automated form (tape 
or disk) in order to save the cost of reentering the data into its computer when 
the data is already in a computer. One consideration is to allow direct access 
to EPA's data bases by the manufacturer in order to improve the timeliness of 
data. If this is allowed, how can access be restricted to only that data 
previously submitted by that manufacturer? 

(2) Each of the 50 states has many rights and responsibilities under the 
various acts coordinated by EPA. Great competition exists among states and 
their legislators for Federal dollars. What data should states be allowed to 
access? As many funding initiatives are based on states' programs, what controls 
can be placed on this data from Congressional and public interest inquiries? 

(3) Members of the scientific community have had great interest in using 
data maintained by EPA. In one instance in North Carolina, technical consultants 
and world-famous employees refused to use picture badges issued for automated 
door locks which controlled access to the research laboratories. How will 
scientists used to having access to scientific informaton react to access controls 
uniformly enforced by the "trusted" ADP system? 

(4) An EPA spokesman estimated that there are now 40 lawsuits by manu¬ 
facturers filed against EPA seeking less stringent environmental controls and 
35 lawsuits by public interest groups filed against EPA seeking more stringent 
environmental controls. Attorneys from both sides commonly use the data bases 
maintained by EPA to support their side of such cases. Attorneys for both sides 
now resort to attacking the integrity of EPA's data bases and data processing 
(including timeliness, accuracy, and completeness of the data) when their case 
is in jeopardy. How can the integrity of data and data processing be sub¬ 
stantiated in a court case? 

EPA's data processing and security requirements were particularly 
interesting to me because they demonstrated that a trusted and provable secure 
computer system was needed outside both DoD and money handling agencies such as 
IRS, Treasury, Social Security and the Federal Reserve System. Unauthorized 
disclosure of classified information and financial fraud are both understood 
problems which have legal histories and penalties. The Privacy Act of 1974 
provides penalties for the intentional disclosure of personal information. The 







draft "Federal Computer Systems Protection Act of 1979," introduced by 
Senator Riblcoff as S.240, makes it a crime to use, for fraudulent or other 
illegal purposes, any computer owned or operated by the United States. The 
bill provides a maximum penalty cf 15 years in prison and/or $50,000 fine for 
willful and unauthorized accesses or attempts to access a computer network 
for the purpose of altering or obtaining programs and data. Without the 
passage of this law, however, EPA has no legal basis to enforce access controls 
Imposed on the very sensitive data supplied by manufacturers, states, cities, 
and private organizations. Yet their most important role is to maintain accurate 
and up-to-date data and be capable of validating its integrity, securely 
processing it for various applications, and assuring its suppliers that the 
data has only been used for its intended purposes. The computer must become the 
"trustee" in this environment and a "trusted” system is necessary according to 
the security requirements of EPA. 

NBS Computer Security Role 

NBS has the responsibility of developing Federal Information Processing 
Standards to improve the utilization of computers in the Federal Government. 
Historically, these standards have included the ASCII character standard, the 
Cobol language standard, magnetic tape standards and computer-peripheral 
interface standards. Now, the Office of Management and Budget has given NBS 
responsibility for developing computer security standards and guidelines in 
Transmittal Memorandum 1 of 0MB Circular A-71. I would like to spend a few 
minutes outlining our computer security program and how we are responding to 
added Impetus to our security program. 

1CST first established a computer security program in 1972 which has: 

(1) Issued six Federal Information Processing Standards or Guidelines 
devoted to computer security. 

(2) Published numerous technical articles and special publications in 
computer security technology. 

(3) Worked with the American National Standards Institute in developing 
voluntary ANSI standards in security of communications and financial trans¬ 
actions. 

(4) Established a five year program to issue Federal standards in the 
following computer security areas: 

o Risk Analysis 

o Contingency Planning 

o Security Auditing 

o Personal Identification 

o Network Security 


o Data Encryption 
o Applications Program Development 











During the first seminar in this series, Dr. Willis Ware of the Rand 
Corporation, in his keynote address, challenged ICST to "step out smartly 
in specifying the performance requirements of a secure operating system 
plus the administrative, procedural and physical environments in which it 
is embedded." Willis stated that "within the Civil Government Sector, only 
ICST has a chance of handling the computer security problem." Willis did 
not say how small that chance was. In support of ICST, Willis did subsequently 
request OMB to provide us reasonable resources to meet this challenge. To 
date, we have received no additional resources in this area. In addition, 
let me outline what I perceive as a set of necessary conditions for anyone 
to meet his challenge. 

(1) A uniform master structure for policies for the protection of 

data within all computer systems of the Federal Government must be established. 

(2) The technology for trusted systems must be researched and developed. 

(3) A willingness to design, build and maintain "trusted" computer 
systems must be made by private industry when the technology becomes 
available. 

(A) A commitment for the procurement and use of "trusted" computer 
systems (when they become available) must be made by all Federal ADP 
organizations when security is needed and physical protection does not 
suffice. 

(5) A standard for the functional requirements of a trusted system 
must be developed and issued. 

(6) A validation service which tests commercial implementations of the 
trusted system against the standard must be established. 

(7) Procurement regulations which make the procurement of trusted 
systems simple must be Issued. 

Dr. Ware called for NBS to follow the same road in developing a trusted 
computer system standard that was followed by NBS in developing a Data 
Encryption Standard. This we will do. We requested the assistance of 
industry and NSA in specifying and evaluating the technology for the Data 
Encryption Standard. I hereby request the similar assistance of industry 
and DoD to research, implement, test and evaluate the technology of a 
"trusted" operating system. NBS can then begin the drafting and coordinating 
of a Federal Information Processing Standard. We can also initiate a 
cooperative effort with DoD in establishing a validation service and with 
GSA in modifying the procurement regulations to make it easy for a Federal 
agency to obtain a trusted system. 

The ultimate impact of computer security in the Federal Government 
cannot be estimated at this time. Even the scope of computer security has 
not been completely specified. Impact will have both positive and negative 








aspects. Processing reliability will definitely be improved because of 
security provisions. Data integrity will definitely be improved, perhaps 
to the point where courts can be convinced of its correctness. Trust of the 
suppliers and users of data will be improved when the computer becomes a 
true "trustee." However, costs will be incurred. People will become 
frustrated when they can no longer access the computer system like they 
could before. Programmers became frustrated (for a short while) when 
they were barred from the computer room. Money must be spent — both for 
initial and operational costs. The acceptability of a trusted computer 
system will be based on these factors. 

NBS is pleased to provide a forum for DoD to discuss its computer 
security initiative with you. We will also be happy to "step out smartly" 
in support of computer security technology and promulgating reasonable 
and effective standards in this area as the technology becomes available. 
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COMPUTER SECURITY INTEREST IN THE PRIVATE SECTOR 

.. by 

Edwin L. Jacks 

General Motors information Systems and Communication Activity 

Good morning. Ladies and Gentlemen. When Dr. Steve Walker 
invited me to speak on the "Computer Security Interest in the 
Private Sector", it gave me a welcomed chance to relate our 
viewpoint on computer security in GM to the computer security 
viewpoint as expressed by the Department of Defense Computer 
Security Initiative Program. 

While the title to my talk is "Computer Security Interest in the 
Private Sector", much of my speech will be on the computer 
security activities within GM. Based on the internal interest 
now being shown by many companies on the subject and discussions 
I have had with data processing managers of other companies, our 
interests are, I believe, similar. 

Computer systems have become a basic resource used in the 
operation of a business. The exception today is the non-use of 
computers in a business function - not the use of computers. 
Their basic utility has been clearly proven. Their penetration 
is into every aspect of business. As reported by The Diebold 
Group, Inc., expenditures for information systems have been 
approximately 1% of the sales revenues for large companies, as a 
national average, for the last 10 years. In GM, one would be 
hard-pressed to find an aspect of the business not using 
computers. The reasons for using computers are diverse: they 
may be economic - a means to reduce operating cost; or business 
effectiveness - a means to better operate the business. The 
private sector is using computers to aid design, engineering, and 
manufacturing of its products; to aid the ordering, marketing, 
and distribution of its products; to aid in the accounting, 
purchasing, and invoicing processes; and to aid in the personnel 
and legal activities of its business. 

The end effect is an extensive business dependency on computer 
systems. 

That dependency has led the private sector into having a basic 
concern about the security of computerized business systems. 
From a strictly technical viewpoint, the only thing that can 
happen to data is the unauthorized disclosure, modification, 
destruction, or delay. 

The private sector concern, however, is with the consequences of 
security failure - for example, loss of production, loss of 
assets, loss of confidentiality, and loss of customer service. 













Information System Security 

As I understand the DOD initiative, its objective is . . the 
widespread availability of trusted computer systems." Those are 
systems with sufficient hardware and software integrity measures 
to allow their use for simultaneously processing multiple levels 
of classified or sensitive information. The broad business 
concern is the prevention of failure for any reason of the 
information system portion of a business system. From a DP 
management viewpoint in the private sector, the security 
objective is to provide business managers with trusted 
information systems. One definition that we have used in GM is 
that, "Security is knowing your business procedures, being 
confident of their operational effectiveness, and beino sure they 
are in place." 

This definition places a positive emphasis on security. It 
emphasizes the need for the business manager to understand the 
computerized portions of his business systems. At the same time, 
it places a responsibility on the system developer to communicate 
clearly with the business manager and to accurately implement 
systems. The operational effectiveness requirement points up the 
need for business managers to evaluate how well a system meets 
business objectives. It identifies his responsibility and 
accountability for a system. And, finally, the "being sure the 
systems are in place", addresses issues of auditability and 
integrity. 

We believe that if the business manager clearly understands the 
computer procedures being used, can measure their operational 
effectiveness, and is sure they are in place, then we will indeed 
have trusted business systems. 

Now, as this audience knows well, from the rigorous mathematical 
viewpoint, the development of trusted computer systems is at the 
front edge of computer technology. However, thousands of 
information systems are working, and working well and are, in a 
practical business sense, trusted. 

If this is the case, then how does the DOD initiative fit into 
the private sector information systems security interest? To 
address that point, the presentation will first cover various 
background aspects of the security activities within GM; second, 
discuss a formulation of security as maintaining, under adverse 
conditions, three independent parameters: availability, 
integrity, and confidentiality; third, discuss design concepts 
for secure systems - in particular, responsibility assignment, 
security continuity, separation of incompatible functions, and 
minimization of failure impact; and, finally, relate the 
preceding items to the DOD initiative. In particular, we find 
trusted computer system concepts necessary but not sufficient for 
the private sector information system security. 
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Securits 


A Pragmatic Approach 


GM is a decentralized organization with major data centers in 
almost every division and in several staff functions. The Data 
Processing Manager at each of these centers has a specific 
responsibility for information systems security. In that most of 
these centers have evolved from the Financial operations in GM, 
they have a long history of careful control and handling of data. 
Their security initiatives are both long standing and pragmatic. 
They install those procedures and practices which economically 
protect their information systems. 

The focus point for a data processing installation’s security is 
the Information System Security Officer - an ISSO. Corporate 
policy requires each data processing installation to have an 
ISSO. He - or she, as the case may be - is the one responsible 
for administering an on-going security program in the 
installation. 

That program would include physical security, operational 
controls, and disaster recovery plans. The operating system 
would be expected to have integrity at least equivalent to IBM's 
MVS system. Any support software required must not violate or be 
detrimental to the system integrity. A resource access control 
program with individual identification and password 
authentication would be in use with the operating system. 

The process of program specification and development would be 
under careful control. Controls would include review and 
approval of program specification by the application manager. If 
appropriate, divisional audit people would also review the 
specification. Particular attention would be paid to the 
processes of final testing and promotion to production. Tight - 
and auditable - controls would be in place to ensure that the 
tested and authorized programs for production are in production. 
Controls would be in place to ensure that the development 
programmer could not change the production program source or 
object code file. In addition, either sample or one hundred 
percent inspections (depending on the sensitivity of the program) 
would be in place to verify the correctness of the program 
relative to the application specifications. 

And finally, within each division, GM has internal auditors to 
provide assurance that information system security procedures are 
in place. 


Security Initiative 


A Staff Stimulant 


In addition to the divisional data processing security activity 
in GM, there are vigorous security activities in the GM 
Coroporate Audit Staff end the GM Information Systems and 
Communication Activity. The Audit Staff has a data processing 












audit group that consists of experienced data processing 
operations, systems development, and operating systems personnel. 
These people, with audit thoroughness and data processing 
expertise, audit the divisional security activities. In 
addition, they aggressively follow the state-of-the-security-art 
to ensure that divisions are using economically effective means 
to improve security. 

The Security group within the GM Information System and 
Communication Activity serves several functions. 

One is consulting with divisions on their overall security 
programs. Another is reviewing the security of various computer 
hardware and software products. A third is coordinating the 
security program activities of the divisional Information System 
Security Officers. A final function is the understanding and 
development of security concepts to support GM's short and long 
term needs for data security. 


Security Objectives 


In working with divisions, we at the staff level get clearly 
challenged by the problems faced by the divisional Data 
Processing Managers in designing their security system. For 
instance, obviously sensitive and critical data should be handled 
in a secure fashion. However, in GM and most private sector 
companies, the words 'sensitive' and 'critical' are informally 
defined as classifications of data.' Often those informal 
definitions pre-date the computer age. The formal classification 
of data requires identification of formal procedures for handling 
each class of data, a requirement for individual clearance for a 
given class of data, and the assignment of the classification to 
each data element. Little utility is seen in the private sector 
for this formal approach to classification. In studying the 
classification of data issue, John Maier of my staff, working 
with divisional ISSOs, was forced to ask, "What are we trying to 
accomplish with classification?” 


Our prime interest was to establish standard classes for both 
information systems and data. This was to be done so that we 
could say that a given application is of a given class and hence 
should be handled with the rules for that class. 


Now what would the rules for a class be? Who has clearance to 
see the data? In GM we, in general, don't clear people; we 
trust them and give them responsibilities so that, at best, 
clearance has to do with need to know. 


Would a rule have to do with timeliness of data and, for 
instance, after a disaster, allowable recovery time? 
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The study found no practical economic and effective 
classification scheme. However, a very positive result occurred: 
it became clear that, for a given system, three independent 
security objectives should be specified. Those objectives were 
identified as: 

Availability - a system's readiness for use; a system's 

ability to receive, to process, and to send 
information in a timely and effective manner; 
a system's ability to recovery from unwanted 
events. 


Integrity 


a system's soundness; a system's accuracy, 
its correctness, and its completeness. 


Confidentiality - a system's closeness; a system's control 

over the access, visibility, and 

dissemination of information. 


The process of establishing availability, integrity, and 
confidentiality requirements was found to relate to some general 
questions. 


1 . 


Who uses 


this information resource? 


2. How is it used? 


3. Where is it sent? 

4. Is this information resource primarily of a financial, 
manufacturing, engineering, sales, marketing, personnel, 
or logist cal nature? 

5. Are there legal requirements for the processing, storage, 
and communication of this information? 

6. Is there existing GM policy which governs the way this 
information is processed, stored, and communicated? 

The particular concerns of availability can be identified by 
examining consequences of loss or delay; for example: 


1. 

What would be the consequences of 
information or processing resource? 

not having 

this 

2. 

What would be 
informat ion? 

the consequences of 

delay of 

this 

3. 

How long can you 

"get by" without it? 



4. 

How current must 

it ue? 
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5. Where must it be available? 

6. Are there alternative means of processing or are there 
alternative sources of the information? 

7. How long must it be accessible? 

8. How quickly must it be accessible in usable form? 

The concerns for inteqrity can be identified by examining 
consequences of incorrectness, such as: 

1. Does this application account for a business operation? 
What would the consequences be if this accounting was 
incorrect? 

2. Does this application direct a business operation? What 
would be the consequences if this operation was directed 
incorrectly? 

3. Does this application specify or control the manner in 
which a process is performed? What would be the 
consequences if this specification was incorrect? 

4. Does this application predict future environments or 
events? What would the consequences be of incorrect 
prediction? 

5. Does this information resource specify the design or 
engineering of products? What would the consequences be 
of incorrect product specification? 

6. Does this application contain business transactions which 
should not be performed by a single individual? 

7. Could manipulation of this resource result in personal 
gain? 

The concerns of confidentiality can be identified by examining 
consequences of improper disclosure. For instance: 

1. Could improper disclosure of this information resource 
result in a breach of personal privacy? 

2. Could this information be considered "inside material 1 '? 

3. Could an individual personally profit from knowledge of 
this information? 

4. Could an individual personally profit from improper 
disclosure of this information? 
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5. 


Who has a legitimate business 
informat ion? 


need-to-know 


this 


6. 

Could GM's competition benefit 
information? 

from 

knowledge of this 

7. 

Which information in the system 
consequences if disclosed to: 

could 

produce undesirable 


a) other departments? 

b) other divisions? 


c) the Corporation at large? 

d) the public at large? 

From answers to these questions comes specific information on the 
requirements for availability, integrity, and confidentiality, 
as well as the consequences of not maintaining the stipulated 
requirements. This information provides a security objective for 
a given application. 

You will note that most data classification schemes tend only to 
address the need for various levels of confidentiality. The work 
on secure computer systems is essentially an effort to provide 
confidentiality by having proven design and implementation 
integrity. From an application standpoint, the availability and 
integrity objectives are only partially improved by the secure 
computer system work. 

Rather than formally classifying data, then, our objective is to 
provide for each application an appropriate level of 
availability, integrity, and confidentiality. 

Security Design Concepts 

In addition to being concerned about clear security objectives, 
we have been concerned about the design process for secure 
systems. In that our security objectives do not relate to a 
formal data classification structure or security model, we must 
in some manner see the security objectives do get incorporated 
into systems. Furthermore, the security objectives for a system 
need to be combined with the system's functional objectives in a 
manner which achieves the security objectives with minimum change 
to the system functional objectives. It would also be desirable 
for the design process for secure systems to fit in with current 
good system design practices. 

Systems can be organized in many different ways to meet 
functional objectives. For example, systems may be organized so 
that the transactions being handled by the systems are handled in 







minimum time; they may be organized for minimum 

inter-connections between system components; or, they may be 
organized to obtain high performance by the people that are part 
of the system. 

The design process usually arrives at a system organization and 
function which is a compromise between objectives. Security 
objectives are often seen as being in conflict with the 
functional objectives for a system. The conflict may be best 
handled early in the design process by deciding on the 
availability, integrity and confidentiality objectives and then 
integrating those objectives into the overall design 
consideration for a system, and into the design of each component 
of a system. The components may well be complex disparate 
elements: people, programs, and hardware. Even with the 

extensive differences between elements, are there design 
principles, particularly relevant to security, which may be used 
to guide the design process? Four principles to consider are: 

First, Responsibility Assignment : the security function must be 
specified for each and every component of a system. 

Second, Security Continuity : the interface between components of 
a system must be identified and must be consistent with the 
security function of each component. 

Third, Separation of Incompatible Functions : system functions 
should be placed in separate components of t'ne system if those 
functions, when performed separately, may serve as a check or 
control on each other and, when performed together, can cause 
system security failure if the component fails. 

Fourth, Minimization of Failure Impact : 
satisfactory system designs, select the system 
minimizes the detrimental impact on the system 
fails. 

The above design concepts for security inter-relate the 
identification of security functions for each component, the 
interfaces between components, and the overall organization of a 
system. 

The first two design principles, responsibility assignment and 
security continuity, are important because they address the 
unique characteristic of security as a distributed property of a 
system, and yet a property in which any component or collection 
of components of a system may cause the total system to not meet 
explicit stated security objectives. The third principle, 
separation of incompatible functions, recognizes that component 
failure may occur, and that, if possible, the system functions 
should be designed to prevent individual component failures from 
causing system failures. The probability of any given component 


given alternative 
organization which 
when a component 
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failing, as well as the consequences of failure, may be used to 
determine to what extent functions need to be separated. The 
fourth principle, minimization of failure impact, is a 
combination of Murphy's Law, "When things can go wrong they will 
go wrong," and a decision theory viewpoint of, "When selecting 
among alternative satisfactory courses of action, select the one 
which will minimize your maximum regret when things go wrong." 


Do Today's Systems Measure Up? 

Data processing security has pragmatically evolved during the 
last 10 to 15 years. It did not come from carefully thought out 
security objectives, nor from carefully applied system security 
design principles. However, the security measures in use today 
can be measured against those objectives and principles. In 
doing that, it becomes clear that there are weaknesses. 
Commercially available computer systems today only in part 
support the building of secure information systems. The security 
objective of maintaining availability, integrity, and 
confidentiality under adverse conditions are not inherent in most 
commercial systems; and the design principles of responsibility 
assignment, security continuity, separation of function, and 
minimization of failure impact were, in general, not used in 
building most commercial systems. 


For example, how can you mix large and small computers in a 
system and have functional responsibility assignments if there is 
no integrity in the computer operating systems? How can you 
achieve continuity of responsibility in a computer system when 
the operating systems, data communication systems, data base 
system, and program library system have independent approaches to 
access control? The problems are well-known to this audience. 

I would like to close by noting that the definition of security I 
used earlier in the talk is in many ways parallel to aspects of 
the Computer Security initiative program. The first part was 
"knowing your business procedures." 

As you are well aware, the process of constructing trusted 
computer systems starts by focusing on a schema for construction 
of computer systems which have proveable properties. In effect, 
that permits a system design team to say, "What we believe our 
system does is exactly what it does." Under those conditions you 
will truly 'know your system'. 

The second part of the definition was "being confident of their 
(the procedures) operational effectiveness." The performance and 
efficiency of the schemas for producing proveable systems is 
still unknown. But, more importantly, will the procedures being 
developed satisfy the security objectives of availability, 
integrity, and confidentiality? With the focus on 
confidentiality, has availability been compromised? At this time 
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I believe the answer is unknown. 


Finally, the last part of the security definition was M . 
being sure they (the procedures) are in place." 

In this regard, the proveability that a desired system property 
is in a system will be a big step forward; and, of course, 
having a trusted computer system as the base for an application 
system is necessary for trusted information systems. 

As I indicated at the beginning, businesses depend extensively on 
computer systems. That dependency will be viewed as almost 
insignificant when compared to the business dependency ten years 
from now. New, large systems will be evolving that will be 
pervasive throughout business organizations. For those systems 
to be secure business systems, the concepts of trusted computer 
systems being developed in the Department of Defense Computer 
Security Initiative Program are clearly needed. 
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1980* TRUSTED SYSTEM APPLICATIONS 










•BELL SYSTEM TRADE/SERVICE MARK 









• WORK PERFORMED BY SYSTEM DEVELOPMENT 
CORPORATION 







APPROVAL FOR DOD USE 
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COMPUTER SECURITY (COMPSEC) 

IMPACTS ON NEAR TERM 
SYSTEMS 


BY 

CLARK WEISSMAN 

SYSTEM DEVELOPMENT CORPORATION 


PRESENTED AT 

SECOND SEMINAR ON DOD COMPUTER SECURITY 
INITIATIVE PROGRAM 

15 17 JANUARY 1980. NBS GAITHERSBURG. MARYLAND 


System Development Corporation 


A DECADE OF COMPSEC TECHNOLOGY 
FUELS GROWTH IN 1980'S 

TECHNOLOGICAL PROGRESS IN: 

1. COMPSEC POLICY 

• INFORMAL DOCTRINE & REGULATIONS 

• FORMAL MATH MODELS 

2 PROTECTION MECHANISMS 

• COMPSEC REQUIREMENTS 

• ARCHITECTURALLY TRUSTED APPROACHES 

3. COMPSEC PRODUCT ASSURANCE 

• CONFORMITY OF PRODUCT — SPEC —* POLICY 

• CREDIBILITY OF EVIDENCE 

--——— System Development Corporation - 
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COMPSEC POLICY IS THE FOUNDATION 
OF THE NEW TECHNOLOGY 


1. INFORMAL DOCTRINE. REGULATIONS, STANDARDS 

• DOD 5200.28 SECURITY REQUIREMENTS FOR ADPS 

• AFR 300.8 ADPS SECURITY POLICY. PROCEDURES. 

AND RESPONSIBILITIES 

- COMPSEC PROGRAM OFFICE 

- DESIGNATED APPROVING AUTHORITY IDAA) 

- SYSTEM SECURITY OFFICER (SSO) 

- CLASSIFIED MODES OF OPERATION 

• AFR 300.13 PERSONAL DATA (PRIVACY) IN ADPS 

• DCID 1 16 COMPARTMENTED INTELLIGENCE DATA 

• OMB A71 THREAT & RISK ASSESSMENT IN ADPS 

• NBS DES UNCLASSIFIED DATA ENCRYPTION STANDARD 

--- Bytarn Pcvdap n i c nt Corporation- 


COMPSEC POLICY IS THE FOUNDATION 
OF THE NEW TECHNOLOGY ICONT'D) 

2. FORMAL COMPSEC POLICY MODELS 

• SECURITY CONDITION - WEISSMAN '69 FJCC 

• ACCESS MATRIX GRAHAM & P. DENNING - '72 SJCC 

• T.H. CONFINEMENT LAMPSON ■ 73 CACM 

• *- PROPERTY ■ BELL & LAPADULA • 73/74 MITRE 

• INFO FLOW - D. DENNING 76 CACM 

• SPECIAL, INA JO FORMAL SPECIFICATION • MITRE. 
SRI, SDC, FACC PRESENT 

• APPLICATION SPECIFIC POLICIES - FUTURE • 1985 

- System Development Corpor a tion - 
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ARCHITECTURALLY TRUSTED APPROACHES 
FOR SECURITY ENFORCEMENT MECHANISMS 
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CHARACTERISTICS OF 
ENFORCEMENT MECHANISMS 

1. PERIODS PROCESSING (P P.) 

• BASICALLY SINGLE APPLICATION ("COLOR") 

PER PERIOD 

• LABOR INTENSIVE. SLOW COLOR CHANGE 

• BREAKS OPERATIONS CONTINUITY 

• USUALLY UNSHARED UNDERUTILIZED CPU 

• NO RISK. NO RUNTIME OVERHEAD 

• CURRENT PRACTICE 

2. JOB STREAM SEPARATOR (JSS) AND CRYPTO SWITCH 

• AUTOMATIC, FAST COLOR CHANGE - TECHNOLOGY 
INTENSIVE 

• TRUSTED PROCESSOR REQUIRED 

• FUTURE DEVELOPMENT IN PROCESS 












CHARACTERISTICS OF 
ENFORCEMENT MECHANISMS (CONT'D) 


3, SECURE NETWORKS END-TO-END ENCRYPTION (E3) 

• MULTI LEVEL NETWORK 

• TRUSTED DEVICES AND PROCESSORS NEED TO BE 
DEVELOPED 

• NBS DES AVAILABLE 

• TRUSTED E3 PROTOCOLS NEED TO BE DEVELOPED 

• £3 IS A TRUSTWORTHY TECHNOLOGY 

• COST EFFECTIVE TECHNOLOGY 

• USEFUL FOR AUTHENTICATION AND ACCESS CONTROL 

• FUTURE DEVELOPMENT IN PROCESS 

4. SECURE SUBSYSTEMS (S3) 

• LIMITED USE. TRANSACTION DMS (TOMS) 

• TRUSTED, MULTI LEVEL TDMS 

• UNTRUSTED OS 

• ONLY TDMS USERS ON OS 

• FUTURE DEVELOPMENT IN PROCESS 

Byttam P eywIO M , tm i L Corporation 


CHARACTERISTICS OF 
ENFORCEMENT MECHANISMS (CONT'D) 

5. SECURITY KERNEL BASED OS 

• FLAW BY FLAW REPAIRED OS UNTRUSTWORTHY 

• TRUSTED, MULTI LEVEL OS WITH KERNEL 

• KERNEL ENFORCES SECURITY POLICY 

• TAMPER PROOF KERNEL 

• KERNEL ALWAYS INVOKED 

• MULTICS AVAILABLE, KVM AND KSOS 1980 

6. CAPABILITY BASED SECURITY 

• TRUSTED, MULTI LEVEL OS 

• SECURITY POLICY ENFORCED BY HARDWARE 
"TAGS”, AND SOFTWARE HIERARCHY 


• FUTURE DEVELOPMENT 











PREDICTABLE IMPACTS BY 1985 


1. INSTITUTIONALIZATION OF COMPSEC TECHNOLOGY 

• INCREASING It KNOWLEDGEABLE MARKET DEMAND 

• INTEGRATED COMPSEC REQUIREMENTS 

• FOUNDATIONS OF A PRODUCT APPROVAL MECHANISM 

2. BURGEONING MARKET FOR TRUSTED PRODUCTS AND APPLICATIONS 

• STIMULATED BY AVAILABLE 

- SECURE OS (KSOS/KVM) 

- VERIFICATION TOOLS (SPECIAL. INA JO. GYPSY) 

• SPECTRUM OF FEASIBLE TRUSTED COMPSEC PRODUCTS 

• MARKET RETARDANTS MAY LIMIT GROWTH 

3 FOUNDATIONS OF A FORMAL SOFTWARE ENGINEERING METHODOLOGY 

• TRUSTED S/W METHODOLOGY RED APPLICABLE TO GENERAL S/W 
COST & RELIABILITY 

• BASED ON SYSTEMATIC. RIGOROUS. MATHEMATICALLY FORMAL 
PROCESS 

• USES INTEGRATED DEVELOPMENT ENVIRONMENT WITH TOOLS TO 
ENFORCE METHOD COMPLIANCE 


Byfm Dwlopmin t Co r po r a t ion 


INCREASING & KNOWLEDGEABLE COMPSEC 
MARKET DEMAND 

1. DOD DRAFTING AND RELEASING GOOD COMPSEC PROCUREMENTS 

• C 3 I 

- KSOS, PSOS, OASIS. WWMCCS. ICCS. KAIS 

• NETS 

- SACDIN, AUTODIN II. ENCRYPTION PROGRAMS. PLI. BCR 

• SPACE 

- SCF UPGRADE. SPACE SHUTTLE. SPADOC 

• LOGISTICS 

- MAC ROC 5-76 

2. FED AND INDUSTRY BUYING 

• NBS 

- RISK ASSESSMENT IR/A) STANDARDS 
GSA 

- ENCRYPTION STANDARDS IDES. 1126. 1127) 

• SSA, HEW 

- FRAUD DETECTION 

- PRIVACY PROTECTION 

• BANKING 

- FED RESERVE EXPERIMENT 

- SACC EFTS 

- BANK EFTS 

• INDUSTRY 

- R/A 

- ACCESS CONTROL (PIN BOX) 

- FRAUD DETECTION 


Byl Wn ' rVwtT i T ii i l Corporation 
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INTEGRATED COMPUTER SECURITY REQUIREMENTS 
CAN BE SEGMENTED BY FUNCTION 


1. DATA CAPTURE AND DISPLAY 

• SUBJECT OBJECT IDENTIFICATION/LABELS 

• AUTHENTICATION AND AUTHORIZATION 

• PHYSICAL ACCESS CONTROL 

2. DATA TRANSMISSION 

• MSG BASED TRAFFIC WITH CONTROL AND TEXT FIELDS 

• ERROR AND TAMPERING DETECTION PROTOCOLS 

• ENCRYPTION OF MSG TEXT END TO END 

• AUTOMATIC ENCRYPTION KEY MANAGEMENT 

3 DATA STORAGE AND RETRIEVAL 

• DATA SECURITY LABELS 

• ITEM LEVEL GRANULARITY 

• ACCESS CONTROL AND LOGGING - OS AND OMS 

• REASONABLENESS ENFORCEMENT (SEMANTIC. LIMITS. TIME) 


Byt«m n awM n rw i m n Coi p en li on 
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INTEGRATED COMPUTER SECURITY REQUIREMENTS 
CAN BE SEGMENTED BY FUNCTION (CONT'D) 


4. DATA PROCESSING AND CONTROL 

• DEDICATED USE NO OPERATIONS AND DEVELOPMENT 

• MIX SENSITIVE DATA ONLY ON "TRUSTED" SYSTEM 

• ACCESS AND AUOIT CONTROL MECHANISM IACM) 

• ACM MUST PROVIDE SELF PROTECTION FOR TRUST 

• ISSO OMS 

• APPLICATIONS MUST SUPPORT HIGHER LEVEL SECURITY PROTOCOLS 

5. FACILITY AND OPERATIONS 

• PHYSICAL PERIMETER/EQUIPMENT ACCESS CONTROL 

• TRUSTED PERSONNEL AND PROCEDURES. ISSO 

• HW AND SW CONFIGURATION CONTROL 

• ISSO MANAGED DATABASE OF SECURITY PROFILES 

• ENFORCED OWNER REVIEW OF AUDIT LOGS 









FOUNDATIONS OF A PRODUCT APPROVAL 
MECHANISM 


1. CURRENT ODD POLICY ADMITS MLS ADPS 

2. DESIGNATED APPROVING AUTHORITY IDAAI ACCREDITS EACH ADPS 

3. DAA'S SUPPORTED BY COMPSEC TECHNICAL ASSESSMENT CERTIFICATION. 
A MAJOR FOCUS OF DOD COMPSEC INITIATIVE 

4. CERTIFICATION BASED ON CREDIBLE EVIDENCE OF ADPS TRUST. EVIDENCE 
COLLECTED OVER SYSTEM LIFE CYCLE 

5 EVIDENCE CREDIBILITY ENHANCED BY 

• SERIOUSLY WRITTEN PROCUREMENT RFP WITH COMPSEC-BASED 
EVALUATION CRITERIA 

• KNOWLEDGEABLE PROPOSAL USING COMPSEC DEVELOPMENT 
METHODS 

• COMPSEC DEVELOPMENT METHODS BASED ON FORMAL 
H/W & S/W ENGINEERING 

• SECURE SYSTEM OPERATION 

6. APPROVED PRODUCTS LIST 

• MARKET SELECTS FROM ALREADY APPROVED PRODUCTS 

• MANUFACTURER BUILDS & SUBMITS PRODUCT FOR DAA 
CERTIFICATION 



SymCam Davalapmant Corporation 
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SECURITY ASSURANCE LIFE CYCLE 






























SYSTEM LIFE CYCLE SECURITY 
OPPORTUNITIES 


LIFE CYCLE PHASES 



I 


OPPORTUNITY 

DO THREAT/RISK/COUNTERMEASURE 
ASSESSMENT 

CONSIDER MAJOR COMMITMENT TO A 
SECURE ARCHITECTURE TO PERMIT 
CONTROLLED SHARING. TRUSTED 
SEGREGATION 

INCLUDE MULTI LEVEL SECURITY TO 
SUPPORT SHARING. PROTECTION 

REQUIRE SERIOUS SECURITY CONTROLS IN 
HARDWARE. OS. DMS. TP. TSS. NETWORKS 

STATE SECURITY THREATS AS FORMAL 
POLICY MODEL 

REQUIRE FORMAL TOP LEVEL SECURITY 
SPECIFICATION WITH CORRESPONDENCE 
PROOF 

REQUIRE SECURITY DRIVEN DESIGN 


SYSTEM LIFE CYCLE SECURITY j 

OPPORTUNITIES (CONT'D) 


OPPORTUNITY 



EMPLOY SECURITY ENGINEERING FOR ADP 
SECURITY 

EMPLOY SPECIAL SOFTWARE METHODOLOGY 
TO PRODUCE TRUSTED SOFTWARE 
REVIEW VENDOR PROTECTION FEATURES 
CONSIDER SECURE SUBSYSTEMS 
REVIEW THREAT/RISK/COUNTERMEASURES 
PERFORM PENETRATION ANALYSIS 
REVIEW COMPLIANCE 
CONSIDER SECURE SUBSYSTEMS AND 
SECURE DISTRIBUTED SUBSYSTEMS 
REVIEW COMPLIANCE. CERTIFICATION. AND 
RECERTIFICATION 

ENFORCE SECURE CONFIGURATION CONTROL 


J 
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PREDICTABLE IMPACTS BY 1985 




1 INSTITUTIONALIZATION OF COMPSEC TECHNOLOGY 

• INCREASING & KNOWLEDGEABLE MARKET DEMAND 

• INTEGRATED COMPSEC REQUIREMENTS 

• FOUNDATIONS OF A PRODUCT APPROVAL MECHANISM 


—2 BURGEONING MARKET FOR TRUSTED PRODUCTS AND APPLICATIONS 

• STIMULATED BY AVAILABLE 

- SECURE OS IKSOS/KVM) 

- VERIFICATION TOOLS (SPECIAL. INA JO. GYPSY) 

• SPECTRUM OF FEASIBLE TRUSTED COMPSEC PRODUCTS 

• MARKET RETARDANTS MAY LIMIT GROWTH 


3. FOUNDATIONS OF A FORMAL SOFTWARE ENGINEERING METHODOLOGY 
• TRUSTED S/W METHODOLOGY R&D APPLICABLE TO GENERAL S/W 
COST & RELIABILITY 


• BASED ON SYSTEMATIC. RIGOROUS. MATHEMATICALLY FORMAL 
PROCESS 


• USES INTEGRATED DEVELOPMENT 
ENFORCE METHOD COMPLIANCE 



ENVIRONMENT WITH TOOLS TO 


C« 


J 


f A 

SPECTRUM OF FEASIBLE TRUSTED 
COMPSEC PRODUCTS 


1. KSOSfKVM ENHANCEMENTS 

• PERFORMANCE TUNING & IMPROVEMENTS (E G., KVM 1.6) 

• FUNCTION ADDITIONS/CHANGES (E.G.. KVM 21 

• NEW HARDWARE BASE (E G.. KSOS/SCOMP] 


2. TRUSTED STANDALONE PRODUCTS (NO KERNEL OSI 

• CRYPTO DEVICES 

- LINE MULTIPLEXING 

- MSG MUX/SWITCH 

- MSG FIELD (E G.. PIN, $. CRCI ENCRYPTION 

- MSG GATEWAY (E G., PIN REENCRYPTORI 

- END TO END ENCRYPTION 

• MLS TERMINAL 

- ENCRYPTION CONTROL (I.E.. KEYS. MSG FIELDS. PROTOCOLS) 

- TRUSTED DISPLAY/COMMANDS IE.G.. RELEASE APPROVAL) 

- CONCURRENT LEVELS IE.G., SPLIT SCREEN & CHAR STREAM) 

- LOCAL ID AUTHENTICATION 

- LOCAL DAT A TYPE ENFORCEMENT (EG., LIMITS. LABELS. LOGIC) 

• JOB STREAM SEPARATOR 

- MLS PROCESSOR CONTROLS LARGER P.P. RESOURCE 


V 













SPECTRUM OF FEASIBLE TRUSTED 
COMPSEC PRODUCTS (CONT'D) 


3. APPLICATIONS EXTENSIONS (KSOS/KVM) 

• S/W UTILITIES 

- CLEAR MEMORY 

- LINK/LOADER 

- EDITOR 

- TRANSLATORS 

- DBUG 

- TEXT FORMATTING 

• SYSTEM ADMINISTRATION 

- LOGIN 

- AUDIT 

- ACCOUNTING 

- SECURITY PROFILE MAINTENANCE 

- RESTART & RECOVERY 

• SECURE DMS 

- MLS OBJECTS 

- FINE GRANULARITY 

- USER VIEW 

- ELECTRONIC MAIUMSG 

- DATA TYPE CHECKER/ENFORCER 

• SECURE NET DEVICES 

- SNFE 

- KDC 

- GATEWAY 

- MUX/CONCENTRATOR 

- SWITCH 

- SANITIZER 

• TRUSTED SfW LIBRARIES 

- APPLICATION ALGORITHMS 

- USER INTERFACES 


- System Development Corpor at ion - 


r 


\ 

MARKET RETARDANTS MAY 
LIMIT GROWTH 


1. TRUSTWORTHY DEVELOPMENT ENVIRONMENT 

• MASTER COPY CONTROL 

• CONFIGURATION CONTROL 

• LIFE CYCLE MAINTENANCE 

• METHODS & TOOLS 

2. TRUSTED COPY DISTRIBUTION 

• TAMPER PROOFED COPIES 

• ROM 

• ENCRYPTION 

• CRC/ECC SCHEMES 

3. INDUSTRY VS GOVERNMENT CONTROL 

• CLASSIFICATION 

• APPROVAL METHODSfPRODUCTS 

• STANDARDS 

• PRODUCTION ECONOMICS 

—- System Development Corpor at ion ——- 
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PREDICTABLE IMPACTS BY 1985 


1. INSTITUTIONALIZATION OF COMPSEC TECHNOLOGY 

• INCREASING ft KNOWLEDGEABLE MARKET DEMAND 

• INTEGRATED COMPSEC REQUIREMENTS 

• FOUNDATIONS OF A PRODUCT APPROVAL MECHANISM 


2 BURGEONING MARKET FOR TRUSTED PRODUCTS AND APPLICATIONS 

• STIMULATED BY AVAILABLE 

- SECURE OS (KSOS/KVMI 

- VERIFICATION TOOLS (SPECIAL. INA JO. GYPSYI 

• SPECTRUM OF FEASIBLE TRUSTED COMPSEC PRODUCTS 

• MARKET RETARDANTS MAY LIMIT GROWTH 


3 FOUNDATIONS OF A FORMAL SOFTWARE ENGINEERING METHODOLOGY 

• TRUSTED S/W METHODOLOGY RftD APPLICABLE TO GENERAL S/W 
COST A RELIABILITY 

• BASED ON SYSTEMATIC. RIGOROUS. MATHEMATICALLY FORMAL 
PROCESS 


• USES INTEGRATED DEVELOPMENT ENVIRONMENT WITH TOOLS TO 
ENFORCE METHOD COMPLIANCE 




' \ 

SYSTEMATIC. RIGOROUS. MATHEMATICALLY 
FORMAL PROCESS 

1. PROCESS STEPS FOLLOW IMPLICATION CHAIN 

• CODE - HOL - SPEC - MODEL - POLICY 

• CORRESPONDENCE (I E.. - ) VALIDATED BY VERIFICATION PROOF 

2 STEPS FORMALLY STATED IN PRECISE LANGUAGE 

• POLICY 

- DIRECTIVE 5200.28 IS DOD STANDARD 

• MODEL (TLS) 

- FORMALIZE ACCESS CONTROL POLICY AS CORRECTNESS 
CRITERIA (INVARIANTS) 

- SUBJECT PROCESSES. MLS OBJECTS 

- INITIAL STATE DESCRIPTION 

- ALLOWABLE (SECURE) STATE TRANSITIONS 

- CORRESPONDENCE TO POLICY BY INFORMAL REVIEW 

• SPEC 

- FORMALLY STATED IN RIGOROUS PREDICATE CALCULUS. 

NON PROCEDURAL LANGUAGES (E G.. SPECIAL. INA JO. GYPSY) 

- TOP AND REFINED LEVELS OF ABSTRACT SPECS 

- VERIFY SECURITY CORRECT BEHAVIOR SPEC TO MODEL 

- SUCCESS AT MITRE, SDC, I P. SHARP. FACC 

• HOL 

- SECURITY RELEVANT PARTS (E G., KERNEL) OF SYSTEM 

- PROCEDURAL LANGUAGE AMENABLE TO VERIFICATION 
(PASCAL, MODULA, EUCLID, GYPSY. ADA) 

- HOL SPEC MAPPING VERIFIED 

- EXPERIENCE LIMITED BUT INCREASING WITH TOOL MATURITY 

• CODE ft HAN 

- ACTUAL EXECUTING PROCESSES 

- VERY LITTLE VERIFICATION ACTIVITY TO DATE HARD AND 
COSTLY RftD 

- COMPILER AND S/W TESTING FOR CORRESPONDENCE 
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TOOL ENFORCEMENT KEY TO 
METHODOLOGY SUCCESS 


1. A NUMBER OF METHODS FOM (SDC). HDM 1SRI). GYPSY (U OF T). 
AFFIRM (USC ISII, PDS (HARVARD*. 

2 all follow top down approach of stepwise design refinement 

3 SPEC HOL MODULES ANALYZED BY TOOLS FOR SECURITY CONDITIONS 
YIELDING PROPERTIES ASSERTIONS TO BE PROVED {THEOREMS} 

• STATE VARIABLES LEGALLY (SECURELY) SET/USED 

• STATE TRANSITIONS RESULT IN SECURE END STATE 

• SPEC PROCESSOR OR HOL VCG TOOLS 

4 THEOREM PROVERS VERY EFFECTIVE 

• AUTOMATIC AND INTERACTIVE TPs IN ACTIVE USE 

• PROOFS LONG & DETAILED. BUT NOT DEEP 

• TP MECHANIZES PROOF BOOKKEEPING. AVOIDS MISTAKES, 
OVERSIGHTS 

• TP FORMATS HUMAN READABLE STEPS TO PROOF. OR TO POINTS 
OF FAILURE 

• PROOF FAILURE INTERACTIVE DESIGN PROCESS 

5 OTHER TOOLS 

• FLOW ANALYZER 

EXAMINES SOURCE CODE DATA FLOW CONSISTENT 
WITH SECURITY LEVEL 

• CONFIGURATION CONTROL 

MAINTAINS SPEC/HOL SOURCE FILES STATUS AND 
DEPENDENCIES LINKED FOR IRE) PROOF 

• TEST CASE GENERATORS 

- USES HOL ASSERTIONS TO AID IN TESTING CODE 

• DOCUMENT CONTROL 

SOURCE TEXT. PROOF. ENGLISH DESCRIPTIONS 


- System Develop m e n t Corporeciort 



PREDICTED IMPACTS 
ARE (MOT SPECULATIVE 


1 INSTITUTIONALIZATION NOW IN PROGRESS 

• NBS. OMB GSA. SSA. 

• DOD SECURITY INITIATIVE'CONSORTIUM 

• GOVERNMENT REGULATIONS 

• INDUSTRY PROCUREMENT INVESTMENTS 

2 MARKET INCREASING 

• A DOZEN OR MORE PROGRAMS IN PROGRESS AT SDC 


3 FORMAL DEVELOPMENT METHODS ARE WORKING 

• EXPERIENCE MOUNTING IN S W RELIABILITY AND 
REDUCED TESTING 

• IMPROVED DOCUMENTATION OF DESIGN 

• SUPERIOR PROGRESS REVIEWS BASED ON RIGOROUS 
SPECS AND PROOF EVIDENCE OF PROGRESS 

• i OOLS ARE WORKING AND BECOMING AVAILABLE 

4 SECURITY PROGRAM STIMULATING MORE COMPSEC R&D 

• NEW COMPUTER ARCHITECTURE IPSOS) 

• DISTRIBUTED PROCESSING 

• BROADER POLICIES MODELS 

- RELIABILITY 

- PERFORMANCE 

- DENIAL SERVICE 
PROTOCOLS 

• S/W ENGINEERING METHODS & TOOLS 


V 
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"Computer Security Impacts on Future 
System Architecture" 

Mr. Edmund Burke 
The MITRE Corporation 

Computer Security Technology 
Future Directions, Future Needs 


Outline 

• COMPUTER SYSTEM TECHNOLOGY 

• HARDWARE AND SOFTWARE DIRECTIONS 

• FUTURE SYSTEM ARCHITECTURES 

• COMPUTER SECURITY DIRECTIONS 

• COMPUTERS 

• NETWORKS 

• NEEDED TECHNICAL STIMULI 
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Computer Hardware 


• GROWTH IS EXPLOSIVE 

• COST/PERFORMANCE DROPPING 
BY ORDERS OF MAGNITUDE 

• VLSI PROMISES-SMALLER, FASTER, CHEAPER 


Computer Software 


• SOFTWARE DEVELOPMENT STILL AN ART 

• CURRENT TECHNIQUES ARE CODIFIED COMMON SENSE 


• SOUND ENGINEERING BASIS STILL SOUGHT 


• ACADEMIC COMMUNITY PURSUING FORMAL TECHNIQUES 
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Distributed Capabilities 



Emerging Systems Architecture 


• PERSONAL COMPUTERS 

• LARGE SCALE UTILITIES 

• COMMON CARRIERS FOR COMPUTERIZED TRAFFIC 
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Personal Computers 


• 0/S AND APPLICATIONS “TUNED” TO A SINGLE USER 

PET, TRS-80 — TOO SMALL 
OS, MULTICS — TOO BIG 
UNIX ® — ABOUT RIGHT 

® UNIX IS A TRADE/SERVICE MARK OF THE BELL SYSTEM 


Personal Computers 

APPLICATIONS 

ELECTRONIC MAIL 
WORD PROCESSING 
PERSONAL FILES 


AGENT FOR ACCESS TO COMPUTER UTILITY 












Large Computer Utilities 


• INFORMATION SERVICES 

• DATA MANAGEMENT SYSTEMS 

• COMPUTATIONAL CAPABILITIES 


Current State of Computer Security 

• SECURE SOFTWARE SYSTEMS EMERGING 

• MANUFACTURERS BEGINNING TO MARKET PRODUCTS 

• INTEGRATION OF COMMUNICATIONS AND COMPUTER SECURITY NEEDED 

• NO COMMON CARRIER OFFERS MUCH 

• SOFTWARE ENGINEERING (& VERIFICATION) TECHNOLOGY 
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Scenario For The Future 



NODE SECURITY NODE SECURITY 


Needed Developments 


• INTEGRATED COMMUNICATIONS AND COMPUTER SECURITY 

• SECURITY FEATURES AVAILABLE FROM COMMON 
CARRIERS 

• WIDER RANGE OF SECURITY EFFECTIVENESS FROM 
MANUFACTURERS 












Needed Developments 


• UNIFORM ACCESS CONTROL POLICY 

• CONSISTENT SET OF SENSITIVITY LEVELS 

• PROVISION FOR ORGANIZATIONAL PREROGATIVES 

• LEGAL STRUCTURE 


Needed Developments 

• FURTHER DEVELOPMENT OF FORMAL ENGINEERING DISIPLINES 

• DESIGN AND IMPLEMENTATION VERIFICATION OF 
CRITICAL SOFTWARE COMPONENTS 

• EXTENSION TO CRITICAL HARDWARE COMPONENTS 








Summary 


• NEW HARDWARE DEVELOPMENTS CHANGING SYSTEM 
ARCHITECTURES 


• CHEAPER DATA COMMUNICATIONS PERMITTING DISTRIBUTION 
OF COMPUTERS 


• INTEGRATED SECURITY CONTROLS NEEDED FOR HETEROGENEOUS 
HOSTS ON INTERCONNECTED NETWORKS 


• FORMALISMS NEEDED TO PROVIDE ASSURANCE OF SYSTEM 
SECURITY 







WHAT EVERY VENDOR ALWAYS WANTED TO KNOW ABOUT 
GOVERNMENT COMPUTER USERS' SECURITY NEEDS 
(but was afraid to ask) 


Dr. Ted M. P. Lee, Sperry-Univao 
Jim Anderson, James P. Anderson, Inc 


[This is written as a questionnaire to be answered by a suitably 
representative sample of government computer customers. The focus is 
mostly on future systems wherein a need for true multi-level security 
might appear, but it is also intended to elicit an indication of the 
current state of affairs wherein security problems are wishfully ignored, 
limited, or avoided by administrative, personnel, or physical security 
measures. It is recognized that most installations are a mix of 
applications and problems, so that a single answer will generally not 
suffice. Note that the questions will for the most part also apply to 
non-government users. The questions have been obtained from an informal 
canvassing of several vendors by T. M. P. Lee.] 

[The answers have been prepared by J. P. Anderson and are an attempt at 
an objective look at the whole issue of computer security and how it is 
handled in DoD and other parts of the Government.] 

[Editor's note: the answers represent the views of J. P. Anderson and do 
not necessarily represent the views of the Department of Defense or of the 
U. S. Government.] 


1. Customer Background 

1.1: Awareness 

Does the customer know what he's talking about? 

Answer: It depends. In some Government units, there is 
considerable knowledge, and much of that is available to 
the managment of those units (e.g. Intelligence 
Community Agencies, some parts of DoD, etc.) In other 
parts of Government activities (e.g. the civilian 
agencies), there is only the vaguest appreciation of the 
problem, and little of the solutions. 

1.2: Point of Contact 

Who is the right person at each agency, department, division, 
etc. to ask these questions of? 

Answer: There is no SINGLE point of contact in each Agency. You 
will get a better perspective on the needs by talking 
with the Data Processing people than with the security 
people. However, the vendors must talk to the ultimate 
customer in order to fully appreciate the requirements. 
In many agencies, the Data Processing people will buy and 
operate computers for an operating branch/activity with 
the substantive application. In these cases, DP is an 
'agent' for the ultimate customer. 
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1.3: Decision Maker 


Who makes the purchasing decisions? 

What does he know or care about trusted computer systems? 

Answer: In general, some form of official or unofficial 

committee. The committee members in general have little 
or no great concern for/about trusted computer systems. 

1.4: Purchasing Criteria 

a) What criteria are used for purchase decisions? 

b) Are there any written standards (viz-a-viz security)? 

c) Where do the criteria come from — internal? user groups? 

law/regulation? gut feel? 

d) How firm and precise are the criteria? Can I see them? 

How will they change? 

Answer: a) and b) It depends on the agency, however, 

compatibility with existing applications/software, other 
hardware units etc. is often the key criteria. Security 
'standards' exist in part, but in many cases, they are a 
recitation of 'nice features’ rather than a functional 
set of security requirements based on the intended use of 
a system. 

As an expample, it might be reasonable for an agency to 
specify that a computer has sufficient mechanism to 
isolate/control transaction users, to include at a 
minimum a user-identification/authentication mechanism, 
and system software to utilize the mechanism, and to 
mantain it. The specification could reasonably describe 
how the resultant system is expected to be used; that the 
system should have sufficient internal mechanism to 
support the building of a 'secure' transaction system, 
etc. The specification may also state that the system 
does NOT have to provide control against 'malicious 
programmers', since all of the customers programmers are 
or will be cleared. (It is a gross understatement that 
such specifications are not commonplace) 

c) The purchasing criteria (security and otherwise) come 
first from internal sources (e.g. DP shop)), leavened by 
regulations that everyone is generally aware of (e.g. 
DOD 5200.28, DCID 1/16, etc.). There is little or no 
'gut feel' . 

d) The criteria are very firm and NOT very precise. In 
virtually every case, they can be seen. The regulations 
undergo more or less continuous change, the changes are 
SLOW, and evolutionary because of the inertia that has to 
be overcome in order to effect change. The source of the 
change is often economic. 
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In order to reduce cost or for some other economic 
reason, a proposal will be made to relax or modify a 
security 'rule'. This is then debated, sometimes 
endlessly and without resolution, but occasionally a 
change will emerge. 

The regulations will evolve as it is possible to 

(1) Demonstrate that a mode of processing hitherto 
thought 'impossible' can be successfully 
supported with only minimun risk etc. 

(2) Show that the economics for making a change are 
favorable. 

1.5; Intangibles 

What intangible factors play a role in purchase decisions? 

— e.g., newness for newness' sake, keeping up with the 

Joneses, gee-whiz technology? 

Answer: There is nothing I can comment on regarding the 
intangibles. I would say that the intangibles regarding 
a vendor, and how he is perceived by a particular 
customer are VERY MUCH more important than any security 
questions and/or the like. 

Data Processing Environment 

2.1: Use 

a) What does the customer do with his computers? 

b) What is the use of the systems by percentage, i.e.: 

communications systems 
data processing systems 
embedded control systems? 

Answer: a) Everything. More and more users are interfacing to 
computers as transaction users. 

b) What kind of systems? If the question is what is the 
expected use of trusted systems (by percentages), then as 
a guess: 


DP 50 - 70* 

Commo 30 - 20* 

Control 20 - 10* 

2.2: Configurations 

What kind of configurations are involved — large/small? 
centralized/distributed? networks? 

Who are his current vendors? 
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Answer: Everything, but: 


a) More networks 

b) From a), more distributed 

c) Large and small 

2 . 3 ' Applications 

What spectrtm of applications are involved: query, limited 
function subsystems, data management, full-scale user 
programming? 

Answer: As noted above, there is more fully developed systems 
(applications) in place, mostly based on interactive 
transactions by users. Batch is still used either as a 
hangover, or as the method of choice for such 
applications as payroll, etc. Even with batch systems, 
there is a some evidence that networks are being used to 
collect files, and disburse the results. 

Full scale user programming is less frequent than was the 
case 10 years or so ago. Except in some 'scientific' 
shops, most programming is done in support of the 
development and or maintenence of transactional/ 
interactive applications, where the bulk of the use of a 
system is concentrated. 

2.U: Security Severity 

What mix of data sensitivity and personnel trustworthiness 
would the customer like to be able to support? 

Can a clearance/classification matrix be given? 

Answer: A VERY Broad brush treatment of the topic. NOT GOVT 

POLICY! (But a guess at what would satisfy if it were 
really available now). 

Civil-Agencies: Privacy Act data, Agency proprietary data, 
and Uncleared people. 

DoD-Low: Secret Confidential and Unclassified Data with users 
at all three levels simultaneously ('true' 
multilevel, low grade) 

DoD-Medium: Top Secret, Secret data, with users cleared at 
Top Secret and Secret levels ('true' multilevel 
— medium) (like AFDSC) 

DoD-High: Top Secret, SCI, with users at TS (only) and 
TS(SCI) levels 

Intel .-Comm.: Top Secret (SCI), TS, Secret, Confidential, 
Unclassified with users at TS(SCI) levels. 
(Need to Know and Proprietary information 
protection also required) 














3. User Security Policy 
3.1: Perception 

a) What does "security" mean to the customer? 

b) Does he care enough about the problem to want the very 
best, or will 02 be good enough? 

Answer: a) Varies with the type of customer. With most, it is 
secondary or tertiary consideration to questions of 
efficiency, functionality, compatibility and the like. 
Most customers DO NOT have a clear, thought-out notion of 
where security fits, or how much emphasis to give it. To 
most, security means badges and access controls at the 
entrance to computer rooms. To the extent that a threat 
is perceived, it is seen as an external threat. 

b) No. 

3.2: Importance 

What is the relative (and ""absolute", if you can determine 
it) importance of the three faces of security — integrity, 
availability, and confidentiality? 

Answer: 


Pelative 

Integrity 2 

Availability 1 

Confidentiality ? 

?.?: Threats 


Absolute 

2 

1 

3 


a) What are the perceived threats to the aspects of security 
mentioned above and what is their relative importance (or 
seriousness)? 

b) Does the customer know or care about the malicious 
programmer threat? 

c) About covert channels and Trojan Horses? 

d) About subversion in the vendor's development and 
maintenance processes? 
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Answer: a) EXTERNA..— MOST organizations are focused on the 
external threat to the exclusion of all others. They are 
incapable of thinking that one of their 'own' could be a 
black hat. Even when they choose to to think of it, 
their a tivities are based in the most part on an 
externa 1 threat except for the relatively simple 
physical/procedural aspects (controlling access to the 
computer center, etc.) 

b) Because of the growing use of transactional systems, 
where users are NOT programmers, most people do NOT see 
the malicious programmer as a serious threat. There are 
very few places where 'general use' programming of 
systems is supported or needed by the operational arms of 
the agency (payroll, personnel, etc. etc.). 
Programmers, where needed are cleared to system high, and 
are not especially controlled. 

c) Huh? Most people do not even acknowledge b). 
Channels are 'academic' finds. They are theoretically 
possible, but are not readily understood by the laiety 
partly because they are NOT considered an importa-.t 
threat since no one today would clear the receiver-agent 
high enough to get access to the transmitter, or the 
receiver-agent would already have full access from being 
a programmer or some such. This is not to say that the 
channels are not important, it is just that they defy 
general solution today. 

d) See b) and c). NO. In general, do not see the threat 
as 'real'. It is in the same class as an airplane 
dropping onto them. Possible, but not very likely. 

3.4: Policy 

Does the customer have a security policy that applies to his 
ADP operations? 

Is it written down? Followed and enforced? 

Answer: In most cases, yes; DOD 5200.28, or AF=====, or etc. 

These policies are followed in the main because they deal 
mostly with tangible things: locks, badges, checklists, 
etc. 

3.5: Access Criteria 

Assuming Harry Smith (or Ivan Ivanovitch) asks to (read 
write, execute, ...) (file, program, record, ...) XYZ, what 
criteria would the customer like to use to grant or deny the 
request? (security labels, privacy requirements, 
"need-to-know" — can anyone say what that means? — access 
lists, ...) 
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Answer: It doesn't really work that way. First, Harry (Ivan) 
is/has to be employed by an Agency/ Contractor etc. His 
JOB must require use of a computer. His BOSS must 
approve (pay for) an account, etc. By the time he gets 
around to asking to Read, Write, Execute and so forth, he 
is already known to the organization, DP shop, etc. His 
access rights are derived from a) his job, b) his 
'clearances' . After that, ALL methods of granting and 
controlling accesss are used; security levels 
(infrequently) privacy requirements (not very common in 
my experience. There is some, but not much), Need to 
Know (often involved, but rarely labeled), access lists 
(proably the most common). Access lists are becoming the 
wave of the future, ORCON as the ultimate in control. 

3.6: Granularity 

Down to what level of granularity of data (e.g., file, 
record, field) is it necessary or desirable to enforce the 
policy? 

Answer: (Yes)**3 

3.7: Role of System 

a) To what extent ought or must the ADP system (operating 
system) make or enforce the decision to grant an access 
request, or to what extent can that be handled outside the 
system without excessively limiting its usefulness? 

b) When do you expect to have enough confidence in the 
"security" system kernel that users may "turn off" other 
protective measures? 

Answer: a) Presently, systems are only marginally involved in 
enforcing access rights. They should be substantially 
involved in the future. 

b) Perhaps never. I don't believe that it was EVER 
proposed that security kernel technology was an exclusive 
solution to the problem. One would still expect to have 
passwords to control access to the system, even with the 
SKT, one might expect passwords to control discretionary 
access (redundantly perhaps), Marking of files/output 
etc, while not a control, is a form of 'protective' 
measure that should/might be retained regardless of 
whether the system operated under an SKT or otherwise. 
The question assumes (as did several other questions in 
this series) that security is a tangible add-on rather 
than an integrated design approach. 
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3.8: Audit 


What security audit records would the customer like to have 
kept? 

What does he keep? 

Is he prepared to process them? 

(How would he like to process them?) 

Answer: None special. Most capture illegal log-on attempts. 

Most SECURITY audit data is weak or not very useful. 
Most users KEEP none of the audit data, except a few 
places that pile up the operators and audit trail logs 
"in case" they ever have to do a damage assessment. To 
be really useful the processing should result in 
exception reports. Six siae inches of listings are not 
very useful as audit data. 

3.9: Special Requirements 

What special technical requirements does the customer have 
that are not covered so far? (e.g., TEMPEST, marking, 
specific human interface protocols.) 

Answer: TEMPEST. Most of the others are left out by and large. 

Technical Security Policy 

4.1: Certification 

a) What does "certification" mean? 

b) Will there ever be an institutionalized process with clear 
and visible standards of acceptance? When? Where? 

c) Who will have the final authority for the "certificate" of 
certification of the secure system software? 

d) How will the DoD go about certifying a system os as to be 
considered "trusted"? 

Answer: a) As a personal observation, it will mean tha^ if 
security is involved in the ultimate application ol the 
system, that buyers will have a hard time justifying the 
buying of uncertified systems. 

b) Yes, by 1985 (+/-) ; in DoD and Intelligence 

communities, not likely in Civilian agencies by then 
because of the relatively short attention span of 

Congress, and others who started the Privacy Act moves. 

c) The buyer. He is the FINAL authority on anything, 

even today, the individual system operator in the USAF 
could make his own independent judgment to run 

multi-level WITHOUT any further blessings or approval. 

d) Pass. 
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A.2: Assurance Measures 


a) What tests/measures/evaluation criteria is the customer 
using, or would like to use, or will use, to assure himself 
that all the technical security enforcement measures in his 
system work as they are supposed to, in the face of the 
perceived threats? 

b) How much does he want to monitor and be involved with the 
vendor's design, development, and support procedures? 

c) Who will maintain the security SW kernel? Since DoD 
maintains/or pays to maintain significant amounts of SW for 
embedded computer systems and other stand-alone systems, why 
shouldn't the DoD plan to do the same for a special security 
package? 

Answer: a) None — Working with the system 

b) None. How much do most people want to be involved in 
the design and production of automobiles faltho since the 
Chrysler bail-out, maybe the will of the country is that 
everyone one wants such invlovment) . In general, one 
wants someone (e.g. an FTC) making sure that the autos 
are safe at some speed, but NOT designing everthing into 
them. 

c) Could be anyone. Maybe a software house such as 
CSC/SDC etc. could/should be the one. 

U. 3: Standardization 

a) Is there any hope for a common direction to emerge across 
a "suitably" large segment of the market place? — i.e., is 
there reason to expect the DoD, Intelligence Community, 
Federal Government as a whole, State and Local Government, 
Private Sector, and Foreign Public and Private Sectors to 
agree (sufficiently) on the nature and extent of the problem 
and on acceptable solutions? 

b) Will multi-level security start to become a mandatory 
requirement in future RFPs where necessary? 

c) Do you plan to specify trusted system requirements for the 
next generation WWMCCS-(WIS)? 

Answer: a) There is already a nunber of 'common' directions: 

language standards, communications standards, etc. 
HOWEVER, most of these standards have been devised or 
heavily influenced by manufacturers in order to permit 
competition (or thwart dominence of the market by one). 
It is unlikely that all of the entities named will see 
much in com won because of their responsibilities AND 
perceptions differ so widely. 

b) Yes 

c) Pass (I would so plan, . ut then, I am NOT WWMCCS etc.) 
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4,4: Technology 


a) Do you have strong biases for one kind of security 
technology (mechanisms or architecture, hardware or software, 
development and verification procedures) versus another? 
Why? 

b) With the availability of the 32 -bit super minis, will a 
requirement for 16 -bit secure minis still be necessary? 

c) What is the government position on software vs. firmware 
security "fixes"? 

d) Do you plan to use ADA as the language for the security 
kernel? If not - why not? 

e) Will a computer system require "special features" in order 
to use the security kernel, i.e., something not in a 
manufacturer's standard product line? 

f) Do you expect the use of the security kernel to require 
changes to the application SW packages; e.g., very little to 
significant? 

Answer: a) Personal biases are; 1. For transaction systems— 
they are common, and THE way commputers have gone and 
will continue to go in the future. 2. For 'distributed' 
(network) systems as models of architectures that should 
be built. 

b) With the availability of 64 bit large machines, will a 
requirement for 32 bit secure minis still be necebsary? 
The question indicates a naive belief that the word size 
is the key issue. The question should be: Is there now, 
and will there continue to be a market for secure minis? 
Answer: Yes. 

c) Beats me. I personally oppose ANY KIND of 'fix'. 
Rather, I would prefer to see the systems used in 
environments where reduced user functionality (e.g. 
transaction systems) limits the risk. 

d) It has been suggested as far as I know, but there is 
no special (pun NOT intended) reason to do so. The 
question is somewhat irrelevant. 

e) 'Special features' are the hall mark of basically a 
single manufacturer. Most others design into their 
systems the basic structures needed for the desired 
functionality, then implement the design in hardware, 
firmware, or software depending on the performance or 
other needs. In order to 'use' (implement) a security 
kernel a machine must aprehend in some fashion the 
concept of 'process'. In order to do this, it may use 
such hardware as 'descriptors', mapping registers, etc. 
Basically the hardware is used to provide efficient 
enforcement of access decisions (i.e. policy decisions) 
made by the operating system. 
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f) For some packages the introduction of a security 
kernel will require significant changes to the package. 
For example, it is possible that the package (i.e. an 
application) itself may be multi-level. If this is so, 
then parts of it may require change (or at least 
partitioning) in order to isolate the multilevel parts. 
On the other hand, in other environments, it may be 
sufficient to group like users of an application, and 
have as many 'copies' of the application as the security 
levels require. 

4.5: Classification 

a) What aspects (how much) of a trusted system is going to 
need to be classified, to what level, and why? (inspection 
or alteration) 

b) How much of a trusted system needs to have been developed 
by cleared people in a cleared facility? 

Ar-wer: a) None should be CLASSIFIED. Some systems may require 
the operational versions to be PROTECTED as classified 
(i.e. handled in trusted channels, etc.). 

b) All of the 'trusted' parts. In most systems this is 
OK for the operating systems. There is still the trusted 
parts of applications built on trusted O.S. that need 
the protection of cleared people, etc. 

4.6: Export 

a) What classes of systems developed and approved for DoD (or 
other government) applications can be marketed and sold to 
other users? 

b) Will there be any foreign export control problems? 

Answer: a) None. 

b) don't think we should export ANY reasonably high 
technology software or hardware. That is just shooting 
ourselves in the foot. 

4.7: Credibility 

a) Why should we pay any attention to "trusted" operating 
systems (especially the current R&D prototypes) when the 
underlying hardware and microcode are getting more 
complicated and hence less trustworthy? 

b) Is the government not exposing a credibility gap by 
seeming to champion software security technology almost to 
the exclusion of hardware security problems and solutions? 
And by so far only producing "toy" or prototype systems? 

c) What is the status of end to end encryption efforts? If 
successful, do you see this method of achieving security 
pre-empting other efforts? 









Answer: a) Hardware and microcode complexity is indeed a problem, 
but one that can be attacked after the software problem 
has been solved. (I guess that is to say that the 
software problem looks easier at the outset). It is also 
true that hardware and microcode complexity makes 
manipulation possible by fewer people (who could be 
controlled by other means?) even if the manipulation may 
be practically undetectable. 

b) There is not a credibility gap in terms of need. It 
is true that most of the efforts have been directed to 
software solutions. This was deliberate for several 
reasons. First, it was believed (and still is) that the 
software problem is 'easier', and more tractable. 
Second. There is/and was research underway in highly 
reliable systems that appeared to bear on the security 
problem at the time. Finally, it was recognized that 
'solutions' that might involve changes to hardware were 
very unlikely to have any impact on the major 
manufacturers since they were for the most part frozen in 
their architectures. Therefore there isn't much room for 
new designs. 

The fact that the solutions have to date been to 'toy' 
problems is in part a reflection of weak resolve. The 
Multics project nearly made it. 

c) Getting there. Even if it meets the most wildly 
optimistic expectations, it will only complement other 
efforts. Secure communications (even end-to-end) is NO 
substitute for secure computers. 

5. Economics 
5.1: Value 

a) How much (assuming that can be given a reasonably precise 
meaning) security is the customer willing to pay for? 

b) How much is he willing to pay? 

c) How much of other things is he willing to sacrifice for 
security (e.g., performance, usability, integrated data 
bases, .. .) 

d) Will government agencies tolerate the necessary 
degradation for certified security systems vs. 
non-kernelized systems? 

e) What impact do you expect to see (in terms of DP system 
degradation) when you use the security system kernel? 

f) Will the government pay the necessary delta for the 
security hardware needed in this type of system? 
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Answer: a) Not too much. The problem is that he gets along 
without it by spending different kinds of dollars (e.g. 
O&M) on different things that do not bear the same 
scrutiny as do Procurement dollars. 

c) and d) 'Performance' might be eroded up to 20-25* in 
some settings without penalty. In most however, no 
detectable performance penalty would be permitted. If 
'degradation' is greater than 50* then the vendor(s) have 
failed. 

e) Varies with the expected use of the system. Present 
versions of the SKT might vary from 25 to 100* depending 
on the hardware upon which it is built, and the 
application for the system. 

f) Only if it is the Nile — it won't pay the 
Mississippi. This question is a reflection that security 
is separable from good design, can be priced, and added 
on like racing stripes and wire wheels. (Where is the 
Necessary River?) 

5.2: Conversion 

How willing is the customer to go through a (minimal, 
moderate, extreme, replacement) conversion (hardware, 
software, or operational procedures) to achieve better 
security? 

Answer: Probably none at all. The challenge will be to provide 
improved security in an 'invisible' (performance/user 
impact) way. Clearly not possible in the large, but a 
goal worth shooting for. 

5.3: Business Forecast 

a) Please forecast future procurements dependent on security 

— $ worth of systems at security level of difficulty X 

(category X in the "evaluated products list"), mode of use Y, 
environment Z? (with specific procurements and dates) 

b) Can you estimate the government market demand for secure 
systems for the next five years? 

c) What will be the first "big buy" that will require MLS? 
What will be the time frame for the first MLS buy? 

Answer: a) ????punt 

b) At the end of 5 years (i.e. circa 1985 (+/-)), it is 
expected that trusted systems will be routinely required 
in all but single-function stand-alone systems. It is 
NOT expected that the Government will make a wholesale 
replacement of existing functioning systems. Once a 
secure system is seen to work, it will become 'standard'. 

c) Ask your marketing people. Now. As soon as it is 
available. 


1-13 











Con petition 
6.1: Questions 

What are you (the customer) asking of my competition? 

Answer: What is UNIVAC (Honeywell, Burroughs, NCR, IBM, 

DEC...etc...) doing? 

6.2: Answers 

What are they telling you? 

Answer: That they (Anyone, not YOUR company) are working on the 
problem, but we (the competition) have the solution. 

6.3: Guesses 

What do you (the customer) think they are going to do? 

Why should I believe what you tell me? 

Answer: Continue working on the problem, then follow IBM. That 
is what most manufacturers do. 
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INTRODUCTION 


I am delighted to participate in these seminars because the objectives 
and efforts of the Computer Security Initiative Program are so closely 
related in theory and practice to the security policy responsibilities 
of the office I represent. Indeed, the initiative itself represents an 
activity many of us realize is long overdue, and it has collectively the 
potential to make a substantial contribution to a number of requirements 
in today's world, well beyond the area of protecting computer processed 
classified information. 

It is both of these areas that I would like to explore today. As a 
point of departure, let me start with a textbook definition of a policy 
as simply a decision made in advance, that is, independent of a specific 
instance or particular situation. A security policy would involve some 
asset of value, seme threat thereto, vulnerabilities and a resultant 
risk scenario, and finally a decision concerning relative allocation of 
resources for protection. 

My primary focus will be upon current policy concepts and their frame¬ 
work, to apply these to the objective of the Computer Security Initia¬ 
tive and to apply these, in turn, to the broader environment established 
by recent OMB (Office of Management and Budget) computer security poli- 








BACKGROUND 


DoD Security Policy Function 

As was indicated, the office I represent is primarily concerned with 
security policy; specifically we function as principal Department of 
Defense advisor on matters of security policy, which in turn includes 
among other things, sensitive information, property and facilities of 
the department world-wide. Our office, moreover^ is also the executive 
management agent for industrial security policy matters for sixteen 
other Executive Branch departments and agencies in addition to the 
Department of Defense, a program which encompasses over 11,000 indus¬ 
trial facilities in the private sector and involves over a million 
personnel security clearances. 

What is common in our program with any effort to secure computer-resident 
information and related ADP assets is the need for a multi-disciplinary 
perspective using diverse talents, a systematic and comprehensive analytic 
approach and ultimately the identification and selection among these 
tradeoffs (Figure 1), involving generally: security, cost, effective¬ 

ness and efficiency factors. 

Nonetheless, in the context of this presentation, the primary security 
function with which we deal involves the formulation and establishment 
of overall security policy for th" protection of classified information; 
that is, Federal Government information and material which, because it 
bears directly on the effectiveness of our national defense and the 
conduct of our foreign relations, must be subject to some constraints 
and protection. 

Problem First Surfaces 

Interestingly, the problem of computer security was first formally 
surfaced in the Office of the Secretary of Defense through the DoD 
Industrial Security Program. In Apri?. 1967, a memorandum sent to our 
office expressed concern for the development of security policy and 
guidance for evaluating the security posture of computer systems, par¬ 
ticularly those in a time-shared mode, and further stressed anticipation 
of a growing use of computers by defense contractors. 

Because of the technical facets of the problem, we solicited the assis¬ 
tance of the Director of Defense Research and Engineering (DDR&E), who 
in June 1967 advised that the Advanced Research Projects Agency (ARPA) 
had been assigned responsibility: to identify the technical aspects of 
the security problems in time-sharing computer operations, to consider 
alternative solutions and to make recommendations for a preferred solu¬ 
tion. Following discussions involving people from the university and 
industrial communities, a task force was formed in October 1967 con¬ 
sisting of a steering group, a policy panel and a technical panel. The 
Task Force was chaired by Dr. Willis Ware who addressed the previous of 
these seminars. 









Nature of the Problem 

The perceived nature of the problem impacting security policy at that 
time is best summarized by the following extracts from an internal 
office memorandum. 

Although the broad policy guidance of DoD Directive 
5200.1 included adequate security guidance at this 
level for single-user ADP systems, it is inadequate 
insofar as the security needs posed by multi-level, 
time-sharing computer systems are concerned. Those 
time-sharing computer systems, in which many files 
of differing security classifications are processed 
simultaneously under the control of several terminal 
operators having differing security clearances and 
validated need-to-know, present a policy problem 
which is nowhere covered adequately by existing DoD 
Directives. 

The Defense Science Board Task Force describes the problem in essen¬ 
tially the same way, in slightly different terms. The 'bottom line' was 
that remotely accessed resource-sharing systems introduced new complexi¬ 
ties and issues, in turn not amenable to solution through the elementary 
safeguard of physical isolation [\]. 

The resultant Defense Science Board Report, entitled, "Security Controls 
for Computer Systems: Report of Defense Science Board Task Force on 
Computer Security," was published in 1*}70, and served as a primary irput 
to the follow on effort to develop responsive DoD ADP security policies. 
This report was mentioned by Dr. Ware at the last seminar, and he has 
since taken the initiative in reprinting and making available copies of 
that report. 

ADP security Task Force . A DoD Security Task Force was established 
under the Deputy Assistant Secretary of Defense (Security Policy) also 
in 1970. Its purpose was fo identify, review and make necessary revi¬ 
sions to security policy directives in order to facilitate the utiliza¬ 
tion of advanced technology in automatic data processing systems. This 
charter, with the Defense Science Board report as input, shifted emphasis 
to the task of developing practical, realistic policy on a Department¬ 
wide basis, a significant undertaking especially at that time. 

DoD Directive 5200.28 and DoD 5200,28-M . Following substantial effort 
by a number of participants, the basic policy documents were written, 
coordinated, and approved. DoD Directive 5200.28, entitled "Security 
Requirements for Automatic Data Processing (ADP) Systems," was published 
in December 1972 and its companion "ADP Security Manual" in January 1973 
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I shall briefly review some of the outlines of the documents to convey 
the security philosophy embodied therein. 
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The policies contained in these documents are designed to provide realis 
tic, cost-effective parameters for the implementation of secure systems, 
with specific recognition given to: limitations in the technical state- 
of-the-art; operational considerations, particularly mission accomplish¬ 
ment; the wide variations within the universe of DoD and contractor 
computer systems; and, the overall potential cost impact of the 
requirements. Key illustrative provisions include the following: 

—That classified material contained in an ADP system shall be 
safeguarded by the continuous employment of protective features in the 
system's hardware and software design and configuration, and by other 
appropriate administrative, physical, personnel, and communications 
security controls. 

—That the basic ADP system reliability and integrity features 
must be augmented to assure that systems which process, store, or use 
classified data and produce classified information will , with reasonable 
dependability, prevent : a. Deliberate or inadvertent access to classi¬ 
fied material by unauthorized persons, and b. Unauthorized manipulation 
of the computer and its peripheral devices; 

—That the diversity and complexity of existing ADP systems as well 
as their demonstrated technical security weaknesses must be recognized 
and that alternative solutions to ADP system security problems are, in 
part, dependent upon the individual characteristics of the ADP system, 
and its usage; 

—That the potential cost of the ADP system dictates that security 
policy be judiciously implemented, carefully managed, regularly reviewed 
and continuously monitored to assure the most effective and economical 
use of the ADP system and related resources of the Department of Defense 
and of its contractors. 


Toward those ends, the Directive provides for the application of admin¬ 
istrative, physical, and personnel security measures to protect ADP 
systems, and includes the explicit assignment of responsibility for the 
testing, evaluation, and approval of such systems and for appointment of 
a responsible ADP System Security Officer for each ADP system approved 
for the processing of classified information. 









POLICY CONTEXT 


Authorities 

Of course, our program is in implementation of and must be consistent 
with requirements imposed by higher authorities. Congress nas enacted a 
number of significant statutes relating to our security program. Further¬ 
more, the President, acting in his capacity as Chief Executive and as 
Commander-In-Chief of the Armed Forces, has issued several Executive 
Orders imposing security responsibilities upon the Secretary of Defense, 
the most pertinent of which is E.O. 12065 (Figure 2} 0*7 

Particularly relevant to implementation of the order in the ADP environ¬ 
ment is the information classification scheme; namely, that national 
security information or material snail be classified :u rue of three 
categories, Top Secret, Secret, or conf ident ■ a I and no tier categories 
shall be used except as expressly provided by statute '.•..her designa¬ 
tions coupled with one of these three categories pertain to access 
restrictions only. 

While the Executive Order focused primarily on the classification and 
declassification of national security material and improving the balance 
between the two competing principles of informing the public and preserv¬ 
ing confidentiality, it also contains other pertinent, broad and generic 
security policy requirements, most of which present problematic judgments 
when applied to the ADP arena. For example, from Section A: 

- "No person tray be given access to classified information unless 
that person has been determined to be trustworthy and unless access is 
necessary for the performance of official duties. 

- All classified information and material shall be marked conspicu¬ 
ously to put users on notice of its current classification status and, 

if appropriate, to show any special distribution or reproduction restric¬ 
tions authorized by this Order. 

- Controls shall be established by each agency to ensure that 
classified information is used, processed, stored, reproduced, and 
transmitted only under conditions that will provide adequate protection 
and prevent access by unauthorized persons." 

Organizational Implementation 

As these requirements are implemented by formal issuances down the 
indicated organizational chains of command, they are elaborated upon and 
generally specified as appropriate to more limited organizations and 
environments. There are also built-in feedback mechanisms for the 
evaluation of lower-level implementations. For example, in OSD, all DoD 
Component implementations must be reviewed and certified as being consis¬ 
tent with the basic DoD issuance. Similarly, the Executive Order provides 
for an "Information Security Oversight Office" to assist the National 
Security Council in monitoring implementation of the Order. One of its 
functions is specifically to "oversee agency actions to ensure compliance 
with this Order and implementing directives . . . ." 
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The EO does not address computers p?r se. Our implementation, the 
Information Security Program Regulation, DoD 5200.1-R, doesn't 

either, except for paragraphs deaLing with various media that may be 
associated with computer processing ( e.g., punched cards, printouts, 
micro-forms). DoD Directive 5200.28 in essence represents our imple¬ 
mentation of the EO insofar as the relatively unique problems posed by 
shared computer systems are concerned. The relationship between the two 
cannot be understated because much of the overall security guidance to 
be applied to the ADP environment is in 5200.1-R and is simply not 
duplicated in 5200.28. Therefore, in developing a system security plan, 
reference to both 5200.28 and 5200.1-R is required. 

(Figure 3) Our ADP security program policies impact not only the DoD 
Components but also those ADP systems processing classified information 
among the 11,500 contractors in the Defense Industrial Security Program. 
As mentioned, this Program is administered by DoD on behalf of sixteen 
other Executive Branch Departments and Agencies, in addition to the DoD 
Components, and currently identified industrial general purpose .ADP 
systems (about 700) represent a significant number of the total .ADP 
systems subject to our ADP security policies. 

"0ther"/Special Access Programs (Figure 4) 

So far the flow of implementation of policy is fairly straight forward. 
But there is always an "other," and as shown, there are basi^.. • four 
sets of Special Access Programs that impact the Informat it u • i. \ city 
Program: 

NATO , where security procedures are based on International Treaty 
Requirements; 

Requirements concerning access to and dissemination of Restricted Data 
and Critical Nuclear Weapon Design Information; 

Special Access Programs for Foreign Intelligence under the cognizance of 
the Director of Central Intelligence or the National Communications 
Security Committee; and, 

Pod "Special Access Programs" as such. 

Our policy in this area is to utilize the standard classification cate¬ 
gories to limit access to classified information on a "need-to-know” 
basis to personnel who have been determined to be trustworthy pursuant 
to the E0 & NSC Directive, so that there will be no need to resort to 
formal Special Access Programs. That is, to avoid requiring the extraor¬ 
dinary procedures and controls, such as formal access determinations, 
special briefings, reporting procedures, and recorded formal access 
lists associated with Special Access Programs. 

For simplicity's sake, consider these four as potential sources of 
additional security requirements in various areas which must be con¬ 
sidered in system security planning, requirements that can range from 
the simple to the very complex and expensive. 
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KEY POLICY PROVISIONS 


Background 

I want to briefly describe some of the key policy provisions and struc¬ 
ture for several reasons: first of all, some of the researchers have 
been using as a point of departure, "old policy," that is, provisions 
that have been superseded. Secondly, the current framework will be 
relevant to any discussion of the fashion in which the output of the 
Computer Security Initiative Program can be applied to an environment 
where formal ADP security policies exj.st. Lastly, in covering key 
provisions, I shall also indicate other aspects of our overall program 
which relate to application of A-71. 

Basic ADP Security Philosophy 

In terms of security concepts, we do not view computer security as 
fundamentally different from the protection of other information and 
material. We do not orient on 100% security as feasible in this area — 
even approaching that level is usually prohibitive in terms of cost or 
constraint. Our approach is to relatively secure by employing security 
barriers and measures in complementary combination (i.e., systematized 
"defense in-depth") so that the cost/risk of penetration exceeds the 
value or payoff of the penetration object, be it personal or classified 
information, nuclear material or monetary assets. This "work factor" 
approach involves identifying vulnerabilities (paths into the "system") 
and erecting barriers generating a "work factor," in terms of cost/risk, 
which exceeds the worth of the object(s) to be protected. 

The end objective is an "acceptable level of risk determination" -- the 
professional security judgment that the security subsystem generates 
such a cost/risk work factor in a comprehensive, systematic and cost- 
effective way. We feel the process through which this determination is 
most effectively and validly made is the security analysis, test and 
evaluation process (Figure 5), wherein both vulnerabilities and counter¬ 
measures are systematically considered. 

The computer security policy problem here is (Figure 6), there are no 
generally accepted standards, criteria or even valid guidelines for 
hardware/software security, yet this overall process is the basic tenet 
of our policy. By contrast there are relatively clearcut guidelines and 
minimum requirements in all the other security areas indicated. The end 
result is that the process cannot now be executed with sufficient confi¬ 
dence in terms of validity or reliability, let alone cost effectiveness. 

It is precisely this problem to which I see the Computer Security Initia¬ 
tive responding. Let me first, however, outline the policy framework 
which I feel can effectively acconmodate the Initiative Program concepts 
as they are evolving — as will be briefed during this seminar. 

Policy Objective 

As a point of departure here is the collective end objective (Figure 7). 
The ADP system's collective security measures must , with reasonable 
dependability, prevent both: 
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1. access to classified material by unauthorized persons, and 

2. unauthorized manipulation of the ADP system. 

Although we are protecting information, in this arena the ADP system as 
such must be protected. The "why" of it has been suggested -- currently 
available systems are penetrable and complex Qe.g., 6,7,8]. Most signifi¬ 
cantly, penetration need not be executed at the time unauthorized access 
to classified information is effected. Rather, a penetration may be 
effected at one time and remain undetected for long periods of time 
prior to exploitation. 

ADP System Security Modes (Figure 8) 

In seeking to accommodate the hardware/software security problem with 
the need to operate, the need to employ ADP system to accomplish or 
support a multitude of defense missions, a set of alternatives evolved 
which may be viewed simply as alternative paths that involve the sorts 
of tradeoffs I mentioned at the beginning. Although not stated as such 
on the slides, one key variable, in the terms of this seminar, is the 
relative degree of "trustedness" insofar as the hardware/software 
security component is concerned. The modes involve basic tradeoffs 
between conventional security measures on one hand and hardware/software 
measures on the other. Viewed as alternatives along a continuum, as one 
moves from left to right relative hardware/software security responsi¬ 
bility increases, along with relatively increasing risk and uncertainty. 

In parallel, relative degree of security cost and constraint tends to 
decrease. The selection of one of these modes for a system is, of 
course, largely dependent upon the specific system, its functional 
requirements, its users and its environment, as to which mode is the 
most cost-beneficial. 

As a further specification (Figure 9), let me relate these modes to the 
two policy requirements for access to classified material. Before an 
individual may be granted access to classified information: 1. he must 
have been granted a security clearance; and, 2. his access must be 
necessary for the performance of his official duties (i.e., he must have 
a "Need-to-Know"). In the manual world, both clearance and Need-to-Know 
determinations are normally made by humans in a fairly straightforward 
way. In the automated environment, however, this can vary. Moving again 
from left to right, clearance and Need-to-Know are determined prior to 
system access in the Dedicated Mode. In the System High Mode, clearance 
is determined before access, but Need-to-Know is not. The double line 
indicates a significant change in hardware/software security role — to 
the right of the lines, it becomes one of preventing outright security 
violations and compromises. Now let's look at some specifics. 

The Dedicated Mode , (Figure 10) at the far left, is the most clearly 
approvable type of system simply because the key security functions I 
noted are formed by comfortable, well understood conventional security 
measures. By definition, everyone with access to such a system has a 







clearance and a Need-to-Know for everything then in the system. The 
major protection burden is assumed by conventional personnel and physical 
security measures and techniques which isolate the system from unautho¬ 
rized personnel, pursuant to fairly clear policy requirements. Hardware/ 
software security role is minimized as a result. 

The Full Multi-Level Security Mode (Figure 11), is at tbe other extreme. 
There are some system users who have neither clearance nor Need-to-Know 
for material contained in the system at the time of their access. In 
this case, in direct contrast to the Dedicated Mode, both clearance and 
Need-to-Know are determined by the ADP system. The separation of users, 
their programs and files must be maintained by hardware/software security 
mechanisms under operating system control, because it's all in the 
computer and potentially accessible at the same time. In terms of 
tradeoffs, the direct security costs and associated constraints on 
system utilization are minimized (e.g., not all users with concurrent 
access need be cleared to the highest levels; remote terminal areas need 
not meet the physical security requirements of the central computer 
facility, cpu (central processing unit) time and system availability are 
not lost through sanitization procedures, and so on). But at the same 
time, hardware/software security responsibilities are now maximized. 

The major burden of key security functions falls upon hardware/software. 

The "System High Mode" (Figure 12). The basic distinction between 
Dedicated and System High is the matter of Need-to-Know. In both cases, 
all users are cleared to the highest level. In the Dedicated Mode, 
Need-to-Know is determined before actual system access is afforded to 
users; in the System High Mode, it is determined by the ADP system 
during access. It is established and maintained by hardware/software. 

This mode is a more flexible, less constraining mode of operating an ADP 
system than the Dedicated Mode. But, election of this mode requires the 
development and implementation of hardware/software mechanisms to imple¬ 
ment Need-to-Know. 

The Controlled Mode (Figure 13) moves one step further along the continuum 
and crosses that significant double line. Neither individual clearance 
nor individual Need-to-Know are predetermined. But, in contrast to the 
Multi-Level Security Mode, the important difference is a set of explicit 
measures to reduce risk and vulnerability and to directly enhance or 
even bypass hardware/software security measures under operating system 
control. 

Basically, the objective here is to provide a potentially approvable, 
interim alternative to the more restrictive Dedicated and System High 
Modes - a transition. But, one must take explicit steps , vice the 
Multi-Level Mode, to reduce relative risk and vulnerability, and, pre¬ 
ferably in combination, other steps to augment the system hardware/ 
software security posture. Examples of risk reduction are limits on the 
range of clearance levels of users who have concurrent access (e.g., 
users of only two clearance levels). Actions that can concurrently 
reduce relative vulnerability include restrictions on users capabili¬ 
ties, such as providing query and response capability (Figure 14). 












Application to Initiative Program Concepts 

I think clearly the most important aspect of the foregoing is the rather 
clear potential linkage between modes, as a continuum of systems on the 
basis of relative required ''trustedness," and efforts of this Computer 
Security Initiative Program, dealing with development of "trusted" ADP 
systems. 

As this slide shows, (Figure 15) there is a clear correlation between 
the relative levels of protection that are evolving for purposes of 
evaluation and the continuum of modes. The left hand column will be 
treated in specifics by Grace Nibaldi and Peter Tasker /5,1Q7 — the 
general point I want to make here is that there is a clear potential 
relationship between the Initiative Program’s efforts and the provisions 
of existing policy. Application of those efforts to real world ADP 
systems through existing policy is therefore neither remote nor obscure. 

The notion here is that one might tentatively select a target system 
s<-curiry mode on the basis of inherent security capabilities in a system 
during the initial stages of the risk assessment (Figure 16). There 
would follow detailed identification and assessment of a host of vari¬ 
ables, both technical and non-technical peculiar to the individual 
system, any of which, in a tradeoff context, might change the relative 
security posture of the system "up” or "down" in the right-hand column; 
that is, with regard to the system security mode ultimately proposed for 
formal approval by the Designated Approving Authority. Jack Adams has 
developed a framework for enumerating critical security considerations 
that can be applied to the middle "interface” column [llj ■ 

The significance of this linkage is now limited to those systems process 
ing classified information in DoD and in industry; as I'll suggest in a 
moment, that significance may be much more profound, depending upon the 
policy framework that ultimately evolves with regard to the computer 
security requirements of Transmittal Memorandum No. 1 to OMB Circular 
A-71. 

From the policy interaction, let me turn briefly to the procedural -- 
how the expertise being developed within the Initiative Program might 
interface with the folks in the field who are currently tasked, and have 
been for some time, with evaluating and approving real world ADP systems 

As a point of departure, let me again refer to the general process that 
is a fundamental tenet of our policy (Figure 17). Recall that other 
than the "hardware/software" area indicated, criteria and requirements 
are relatively clear. Also given both resource limitations and the 
highly technical nature of the task, it appears most likely that 
formalized establishment of the Initiative Program’s expertise will be 
at least initially centralized. 

The technical expertise can be integrated into the test and evaluation 
process as shown here, by complementing the ongoing Component activities 
in the technical area. Recall that our policy explicitly delegates ADP 
system security approval authority to the DoD Components (and DLA for 
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contractor ADP systems). It is not our intention to change that — the 
final approval must be on a system-by-system basis; that is, keyed to an 
individual system with its unique environment and functional requirements. 


Though this is an old slide (Figure 18), it shows the place of technical 
advice, indicated in red, in the overall Component evaluation process. 

It also indicates our intent that the overall synthesis of the diverse 
parts of the analysis, together with the final decision to approve or 
not approve, lies with the appropriate Component Designated Approving 
Authority. 

This overall notion might be kept in mind as I pursue the projection of 
classified arena concepts to a broader environment in ADP security. 
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A STRUCTURED CONCEPT FOR A-71 IMPLEMENTATION 


Thus far, we have been discussing exclusively the policy framework for 
the protection of classified information in the ADP environment (Figure 
19). As most of you are aware, the Office of Management and Budget 
promulgated much broader ADP security requirements in July 1978, 
specifically Transmittal Memorandum No. 1 to OMB Circular A-71, entitled 
"Security of the Federal Automated Information Systems" [\2j. This is a 
truly omnibus policy in that it is concerned with more than information 
security per se and more threats than just unauthorized disclosure of 
national security information. A-71 establishes a number of responsibil¬ 
ities and imposes a number of requirements on Executive Branch agencies. 

A-71 Responsibilities and Requirements 

To consider this document and its potential relationship to the Computer 
Security Initiative Program, let's first briefly review the scope and 
content of the program. First, it covers all Federal data and applica¬ 
tions processed by computer. 

This new program requires each Executive Branch Agency to: 

- Assign responsibility for the security of each computer installa¬ 
tion operated by or on behalf of the agency to a management official 
knowledgeable in data processing and security; 

- Establish personnel security policies for all Federal and contrac¬ 
tor personnel involved in the design, operation, or maintenance of, or 
having access to data in, Federal computer systems; 

- Establish a management control process to assure that appropriate 
administrative, physical and technical safeguards are incorporated into 
all new computer applications and significant modifications to existing 
applications (for applications deemed "sensitive," this includes: prior 
definition and approval of security specifications and the conduct, 
approval and certification of design reviews and application systems 
tests); 

- Assure that appropriate security requirements are included in the 
specifications for the acquisition or operation of computer facilities 
or services; 

- Conduct periodic risk analyses for each computer installation 
operated by or on behalf of the agency (at least every five years); 

- Conduct independent periodic audits or evaluations and recertify 
the adequacy of the security safeguards of each operational sensitive 
application (at least every three years); and, 

- Assure that appropriate contingency plans are developed and 
maintained to provide for continuity of operations should events occur 








which prevent normal operations; periodically review and test these 
plans. 


Also under the new program: 

- The Department of Commerce will develop and issue computer system 
security standards and guidelines; 

- The General Services Administration will issue policies and 
regulations for the physical security of computer rooms and assure that 
security requirements are included in agency procurements; and, 

- The Civil Service Commission (now Office of Personnel Management) 
has established personnel security policies for Federal personnel asso¬ 
ciated with computer systems £l3j • (Their guidelines also imply appli¬ 
cability to contractors.) 

DoD Implementation Approach 

The approach we are pursuing in Defense is one of essentially applying 
to the A-71 requirements the ADP security policy framework that has 
evolved in the classified arena over approximately the past decade. 
Essentially, (Figure 20) we envision first categorization of data and 
applications on the basis of criteria analogous to those that exist for 
classified national security information. Secondly. ADP systems are 
primarily categorized in terms of the data/applications processed, and 
then specific systems security requirements are directly derived pri¬ 
marily on a system basis. Incorporated, of course, is the multi¬ 
disciplinary, systematic approach to implementation that characterizes 
the classified arena. A third essential ingredient, directly relevant 
to the computer security initiative program, is utilization of the 
currently authorized system security modes discussed above. 

Let me quickly review the data and application categories that we have 
proposed in the intended sequence. Recall in this regard that Dr. 

Burrows (Director, Institute for Computer Sciences and Technology, NBS) 
earlier here called for development of a uniform structure for protection. 

Sensitivity Categories — Data i AgfiiiSatigng. (Figure 21) 

ADP I, "Critical-Sensitive". DoD data and applications stored or processed 
in, or communicated, displayed or disseminated by, an Automatic Data 
Processing (ADP) System shall be categorized as ADP I when one or more 
of the following criteria are met: 

- Top Secret National Security Information — The data or applica¬ 
tions require protection in the interest of national security, and the 
classification designation is "Top Secret" (DoD Regulation 5200.1-R); 

- Mission Critical -- The data or applications are such that the 
denial of use, loss, compromise, disablement or unauthorized alteration 
thereof could reasonably be expected to directly and gravely degrade or 








jeopardize the capabilities of a Military Department, the Joint Chiefs 
of Staff, a Defense Agency or a Unified or Specified Command to timely 
and effective discharge of their primary functions (DoD Directive 5100.1) 
in support of DoD emergency and/or war plans; 

- Lil e Critical -- The data or applications are such that the 
denial of use, loss, compromise, disablement or unauthorized alteration 
thereof could reasonably be expected to directly and gravely jeopardize 
human life; 

* Auto mated Decislonma king Systems -- Applications, not otherwise 
included in the foregoing, which issue checks, requisition supplies or 
perform simi' lr assets control functions, based on pro’rammed criteria 
with little human intervention, wherein the potential loss or exploitable 
monetary value at the assets handled could exceed 310,000,000 per year. 

ADD 11. "No ncri tica 1-Sens it 1 ve ". DoD data and applications, which do 
not meet any of the foregoing criteria for category ADP I, shall be 
.ategorized as ADP II when one or more of the following criteria are 
met : 

- Se cret or Confidential Jutlw.-.l Security Info r mation -- The data 
>r applications require protection in the interest of national security, 
ind the classification designation is either "Secret" or "Confidential" 

DoD Regulation 5200.1-R); 

- Miss ion Critical — The data or applications are such that the 
denial of use, loss, compromise, disablement or unauthorized alteration 
thereof could reasonably be expected to degrade or jeopardize component 
command or major staff element capabilities to support timely and effec¬ 
tive discharge of Military Department, OJCS, Defense Agency or U & S 
Command miss ons and functions; 

- Privacy -- The data or applications involve personal information 
requiring protection pursuant to the Privacy Act of 1974 (DoD Directive 

- FO IA Exemptions -- The data or applications (unclassified) have 
been determined to be exempt from public disclosure, consistent with the 
requirements of the Freedom of Information Act (FOIA) (Section VI, DoD 
Directive 5400.7); 

- Aut omated Decisionmaking Systems — Applications, not otherwise 
included in the foregoing, which issue checks, requisition supplies or 
perform similar assets control functions, based on programmed criteria 
with little human intervention, wherein the potential loss or exploitable 
monetary value of the assets handled could range between $1,000,000 and 
$10,000,000 per year. 

ADP III, "M o nsensitive ". All other DoD data and applications which do 
not meet the criteria for categories ADP I or ADP II as set forth above. 
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ADP I, "Critical-Sensitive". ADP systems shall be categorized as ADP I 
when either of the following criteria is met: 

- ADP I Data or Applications — The ADP system stores or processes 
one or more sets of data or applications categorized as ADP I, "Critical- 
Sensitive," pursuant to the criteria herein; or, 

- Automated Decisionmaking Systems — The ADP system handles "auto¬ 
mated decisionmaking systems" wherein the aggregate total potential loss 
or exploitable monetary value of assets handled collectively by the ADP 
system's automated decisonmaking systems applications could exceed 
$10,000,000 per year. 

ADP II, "Noncritical-Sensitive" . ADP systems, which do not meet any of 
the foregoing criteria for category ADP I, shall be categorized as ADP 
II when either of the following criteria is met: 

- ADP II Data or Applications — The ADP system stores or processes 
one or more sets of data or applications categorized as ADP I; or, 

- Automated Decisionmaking Systems — The ADP system handles "auto¬ 
mated decisionmaking systems" wherein the aggregate total potential loss 
or exploitable monetary value of assets handled collectively by the ADP 
system's automated decisionmaking systems applications could fall between 
$1,000,000 and $10,000,000 per year. 

ADP III, "Nonsensitive" . All other ADP systems processing DoD data or 
applications. 

Sensitivity Categories — Personnel Positions (Figure 23) 

ADP I, "Critical-Sensitive''. Positions of personnel requiring access to 
ADP I DoD data or applications OR unescorted access to an ADP I ADP 
system(s). 

ADP II, "Noncritical-Sensitive" , Positions of personnel requiring 
access to ADP II DoD data or applications OR unescorted access to an ADP 
II ADP system(s). 

ADP III, "Nonsensitive" . Positions of all other personnel requiring 
access to DoD data or applications OR requiring unescorted access to an 
ADP system containing DoD data or applications. 

Now when we link the foregoing to the system security mode concepts 
already presented, we have the capability to minimize personnel security 
clearances for systems, based, in the terms of this seminar, on the 
relative "trustedness" of the internal system security controls. For 
example: 













Adjustments for Position Sensitivity Categories (Figure 24) 

1. "Multilevel and Controlled Mode" Systems — The positions of 
ADP System Users with access to systems already approved to operate in 
either the "Controlled Security Mode" or the "Multilevel Security Mode" 
pursuant to DoD Directive 5200.28 (or, for contractor ADP systems, DoD 
Manual 5220.22-M) shall be designated in the position sensitivity cate¬ 
gory commensurate with the most sensitive category of the DoD data or 
application(s) they will access under system constraints. 

2. "Temporarily Dedicated" Systems — The positions of personnel 
with access to ADP systems currently operating under procedures that 
effect temporary dedication to different sensitivity categories at 
different periods of time (also called "color changing" or "periods 
processing”) shall be designated in the sensitivity category commen¬ 
surate with the most sensitive category of DoD data or applieation(s) 
contained in the system during periods of each individual's access to 
the system. In remotely accessed systems, this will include remote 
terminal users wherein the remote terminal is disconnected during higher 
sensitivity category processing periods. 

3. "Output Only" — The positions of ADP System User personnel 
shall be designated in the position sensitivity category commensurate 
with the category of only the system output they actually receive when: 
(1) such personnel do not input to or otherwise directly interact with 
the system (i.e., no "hands on” or other direct input or inquiry capa¬ 
bility), and (2) the output products are either reviewed prior to 
dissemination or otherwise determined to be properly identified as to 
content, intended recipient and sensitivity category (i.e., systems 
approved to implement this option pursuant to paragraph IV.C.5.b., DoD 
Directive 5200.28 or for contractor ADP systems, paragraph 108, DoD 
Manual 5220.22-M). 

4. "Technical Review" — The positions of personnel who design, 
develop or generate DoD data or applications, or who generate input to 
an ADP system containing DoD data or applications, shall be designated 
in a less sensitive position category when (1) such personnel do not 
have access to ADP systems containing higher sensitivity category data 
or applications, and (2) when the product or input generated by such 
personnel is subject to "Technical Review.” 

The most important consequence of the foregoing is that if we pursue 
this concept then the need for "trusted" systems, just within Defense, 
will expand from potentially 27% of our inventory (the subset that 
processes classified information) of general purpose ADP systems to 
100%. With Defense contractors, the requirement is expected to also 
increase, although there is no basis for anticipating specific numbers. 
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Executive Branch Implementation 

A-71 implementation from an Executive Branch-wide perspective generates 
a number of problems, particularly when data/application interchange 
among agencies and departments is considered, and most notably when 
contractors additionally are involved. 

Personnel Security 

The first and perhaps the simplest aspect of A-71 implementation, rela¬ 
tively speaking, that was promulgated was in the area of personnel 
security by the Office of Personnel Management (OPM), pursuant to 0MB 
tasking /T3 J. As might be expected, the OPM criteria and guidelines are 
primarily keyed to the existing personnel management structure and are 
oriented on individual personnel positions. The foregoing concepts, 
however, are oriented on a system basis, and general personnel security 
requirements as well as other general requirements, may be derived from 
system security level and system security mode. 

Specific requirements in the personnel security area are essentially 
open ended insofar as the scope of personnel security investigations, 
the standard which an individual must meet to be eligible for assignment 
to an ADP position and the adjudicative criteria by whicu the individual 
will be judged to determine whether the standard has been met. From an 
Executive Branch-wide perspective with regard to contractors, such a 
decentralized approach can result in an uncoordinated effort which (1) 
may not provide a uniform degree of fairness to the subjects of the 
investigative/adjudicative processes, (2) would not tend toward mutual 
and reciprocal acceptance of personnel security determinations among 
Federal agencies, and (3) cause confusion among firms performing on AOP 
contracts with more than one Federal agency (also possibly requiring 
duplicative or repetitive investigation of contractor employees to meet 
different scope and adjudication criteria). 

With these very real and significant concerns in mind, we prepared 
correspondence for 0MB, which the action office for A-71 in DoD has 
already formally dispatched. We specifically proposed that the majority 
of the problems cited could be avoided by following the single executive 
agency concept of the Industrial Security Program, established under the 
provisions of Executive Order 10865. The Executive Order recognized 
that conflicts and lack of uniformity would result if each government 
agency in the classified arena implemented its own industrial security 
program, and it therefore provided for the extension of the DoD program 
to include other departments and agencies. As a result, DoD has execu¬ 
tive agreements with 16 other Executive Branch agencies to provide an 
industrial security program on a cost reimbursement basis. Consequently, 
standardized requirements and procedures have been issued and are uni¬ 
formly implemented by participating agencies and contractor facilities 
Moreover, investigations are conducted in accordance with a 
standard investigative scope and are adjudicated centrally by the Defense 
Industrial Security Clearance Office under uniform adjudicative criteria. 
Records of clearances are also centrally maintained. The major benefit, 
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however, is that industry does not have to contend with 17 different 
government security programs. 


We accordingly recommended that the implementation of the contractor 
employee personnel security requirements of A-71 be carried out by means 
of a modification of the Industrial Security Program. 

Beyond Personnel Security 

As I suggested, the personnel security aspect of A-71 is in many respects 
the simplest. The logical extension of the foregoing suggest additional 
possibilities. 

For example, the Industrial Security Program does more than the indicated 
central personnel security clearance function; it also inspects specific 
contractor facilities and issues and records "contractor facility clear¬ 
ances”* on behalf of the 17 participating Federal Organizations. More 
to our concern here, for a decade our Industrial Security Representatives 
have been inspecting and approving contractor ADP systems that process 
classified information. 

It takes little imagination, therefore, to suggest that the same logic 
that argues for serious consideration of centralized handling of con¬ 
tractor personnel security likewise, or even more so in light of the 
innate complexity of the total A-71 tasks, suggests equally serious 
consideration be given to at least uniform handling of contractor ADP 
systems and related protection of Federal government data and applica¬ 
tions pursuant to A-71. 

I would further suggest that if two of the notions outlined above were 
specifically included, the resultant practical framework for a total 
program implementation, both in and out of government, would be sub¬ 
stantially simplified. That is, if: 1. a categorization scheme for data 
and applications were implemented government-wide and 2. if mode concepts 
were adopted, then a ready-made policy framework would be rather easily 
created. It would further provide for substantial effort being directed 
to the truly difficult issues in A-71, whereas by contrast, the absence 
of such a framework would generate questions and issues that could be 
the subject of virtually endless debate, to the detriment of meaningful 
progress on effectively implementing the other charges of A-71. And if 
there is one consistent problem throughout the ten-year history of our 
classified ADP security program, it is a shortage of manpower — that 
is, manpower per se; never mind the issue of the qualification of the 
people. 


"An administrative determination that, from a security viewpoint, a 
facility is eligble for access to classified information of a 
certain category (and all lower categories)" [\kj . 


J-19 





A measure of precedent for a categorization scheme for Federal data and 
applications exists in the OPM guidelines by virtue of their correlating 
varying personnel security requirements to those established by Executive 
Order 10450 for the traditional national security area. Such categori¬ 
zation would provide, unlike the privacy area, discrimination between 
relative sensitivity and relative allocation of security resources 
generically. 

Addition of the standardized mode concepts, with the above, would sub¬ 
stantially simplify the overall risk assessment process at the general 
level and permit focus on those complex security aspects which are truly 
installation and system dependent. 

Further, at least within Defense and among Industrial Security Program 
contractors, such an approach would eliminate a substantial portion of 
learning curve costs for people working with those ADP systems by employ¬ 
ing a framework that has been in being for almost a decade. It's not 
perfect : but it has had a long "debugging" period. 

In a phrase, it thus would provide "one face to industry" comprehensively . 
It would concurrently provide an implementation framework for the han¬ 
dling of intra-government flow of data and applications processed by 
computer, among Executive Branch agencies and departments, a flow which 
I understand is not insignificant in volume. 


CONCLUSION 

In summary, there is a policy framework which has evolved in computer 
security over a ten-year period that is in effect within the Department 
of Defense and in the Defense Industrial Security Program. Moreover, on 
the industrial side, there is an in-being, nation-wide system that h3s 
likewise been in operation for about decade. Implementation along the 
lines suggested above would virtually solve a number of serious potential 
problems relating to Government interface with the private sector and 
the intra-government flow of data and applications processed by computer. 
It would also provide for direct application of the "trusted systems" 
being developed through the Computer Security Initiative Program. 

The mapping of such a proven and rather well accepted policy framework 
to A-71, particularly commonly accepted and operationally defined notions 
of "cleared people" and "approved systems," I believe warrants serious 
consideration and further exploration for the reasons given—I would 
most appreciate your views on this. 
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THE BASIC ADP SYST EM RELIABILITY AND INTEGRITY FEATURES 
MUST BE AUGMENTED TO ASSURE THAT SYSTEMS WHICH PROCESS, 

STORE. OR USE CLASSIFIED DATA AND PRODUCE CLASSIFIED 
INFORMATION WILL, WITH REASONABLE DEPENDABILITY, PREVENT : 

A. DELIBERATE OR INADVERTENT ACCESS TO CLASSIFIED MATERIAL 
BY UNAUTHORIZED PERSONS, AND 

B. UNAUTHORIZED MANIPULATION OF THE COMPUTER AND ITS 
ASSOCIATED PERIPHERAL DEVICES. 
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SYSTEM SECURITY PROCESS, OBJECTIVE & CONSIDERATIONS 
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It IS THE OBJECTIVE OF MY PRESENTATION/ to make you familiar with 
THE ADP-SECURITY REQUIREMENTS WE HAVE ESTABLISHED FOR OUR EIFEL 2 
SYSTEM. 

In ORDER TO HELP YOU TO UNDERSTAND THESE REQUIREMENTS/ THE FIRST 
PART OF THIS PRESENTATION WILL BE A SHORT DESCRIPTION OF EIFEL 2 
FROM AN OPERATIONAL AND TECHNICAL POINT OF VIEW AND THE SECOND 
PART WILL BE USED TO GIVE YOU A CONCISE PRESENTATION OF THE SE¬ 
CURITY REQUIREMENTS. 

1. Introduction 

The German Air Force currently develops a Command, Control and 
Information System, which will assist the military commanders 
in the Air Force at all levels of command by supporting their 
command and control tasks with modern information processing 
equipment. 

This system will be realized in several stages, first parts 
are scheduled to become operational in 198A. 

This ADP-supported CCIS of the German Air Force will consist 
OF A BASIC SYSTEM, CALLED EIFEL 2, WHICH ONE MIGHT CALL THE 

ADP-workhorse of the GAF-CCIS and several software-subsystems 
WHICH will be implemented ON EIFEL 2. 

2. Description, of EIFEL 2 

EIFEL 2 AS THE BASIC SYSTEM WILL PROVIDE FOR THE FOLLOWING 
FUNCTIONS: 

- COLLECTION, STORAGE, DISTRIBUTION AND DISPLAY OF STATUS IN¬ 
FORMATION 

- REPORTING SYSTEM FOR ALL GAF-UNITS 


- DISTRIBUTION OF ORDERS AND MESSAGES 









- COMMON DATABASE FOR ALL SUBSYSTEMS 

- PROCESSING CAPABILITY FOR ALL SUBSYSTEMS 

- INTERFACE TO NATIONAL AND NATO SYSTEMS 

At this point in time, we envision 3 subsystems: 

- ONE SUBSYSTEM TO SUPPORT THE MISSION PLANNING PHASE FOR 
TACTICAL OFFENSIVE AIR-POWER BY PROVIDING SPECIAL APPLICATION 
FUNCTIONS, 

This subsystem is called DISTEL; 

- ONE SUBSYSTEM TO SUPPORT THE MISSION PLANNING PHASE FOR 
TACTICAL AIR-LIFT FORCES BY PROVIDING SPECIAL APPLICATION 
FUNCTIONS. 

This subsystem is called SYLT; 

- ONE SUBSYSTEM TO SUPPORT THE "MISSION PLANNING PHASE" FOR 
LOGISTIC FORCES BY PROVIDING SPECIAL APPLICATION FUNCTIONS, 

This system is called SUSYLOG; 

This philosophy with one basic system and several subsystems 

WHICH WILL BE IMPLEMENTED ON THAT BASIC SYSTEM IN LINE WITH THE 
OPERATIONAL REQUIREMENT FOR HIGH AVAILABILITY AND SURVIVABILITY 
OF THE DATAPROCESSING POWER HAS RESULTED IN A SYSTEM ARCHITECTURE 
WITH THE FOLLOWING MAIN CHARACTERISTICS: 

- EIFEL 2 WILL CONSIST OF ADP-CENTERS, WHICH WILL BE DISTRIBUTED 
OVER THE TERRITORY OF THE FEDERAL REPUBLIC OF GERMANY; 

- THERE WILL BE AN INTEGRATED DATABASE, WHICH WILL BE DISTRIBUTED 
OVER THESE ADP-CENTERS; 

- ADP-CENTERS AND USERS WILL BE CONNECTED BY A PACKET-SWITCHED 


NETWORK; 






[ 


A SCHEMATIC PRESENTATION OF THE SYSTEM ARCHITECTURE SHOWS 
THAT EIFEL 2 WILL CONSIST OF 

- HOST OPERATING CENTERS, TO PERFORM THE DATAPROCESSING TASKS, 

- Basic Data Processing Centers, which have in general the 

SAME DATAPROCESSING TASKS AS THE HOST OPERATING CENTERS, BUT 
ARE OF A SMALLER SIZE, 

- Terminals, which will be placed directly on the users desk, 

- A NETWORK CONNECTING USERS WITH DATAPROCESSING CENTERS AND 
USING PACKET-SWITCHING TECHNOLOGY, 

- HOST Interface Processors, Terminal Interface Processors and 
Foreign Systems Interface Processors to realize the different 

INTERFACES TO THE NETWORK, 

Let ME GIVE you now a short LOOK ON the ESTIMATED numbers of 
BASIC HARDWARE COMPONENTS WE THINK WE WILL NEED FOR EIFEL 2: 

18 HOST OPERATING CENTERS 

46 Basic Data Processing Centers 
35 Packet-switches 

24o Terminal Interface Processors and Foreign Systems 
Interface Processors 

- 2ooo Terminals 

- 18oo Crypto Devices 

5o Alphanumeric Large Screen Displays 
5o Graphical Large Screen Displays 

I WILL NOT GO INTO THE DETAILS OF THE SUBSYSTEMS, BECAUSE‘AS 
MENTIONED BEFORE, THE SUBSYSTEMS ARE ENVISIONED AS "APPLICATION 
PACKAGES" WHICH W LL RUN ON EIFEL 2. 

From the sfcup t ',y point of view, their security requirements 

WILL BE REALIZED THROUGH EIFEL 2, THEREFORE IN THE FOLLOWING 
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PART OF MY PRESENTATION, I WILL ONLY DISCUSS THE SECURITY RE 
QUIREMENTS FOR EIFEL 2. 


, ADP-SECURITY REQUIREMENTS 

Let me start with our definition of security for EIFEL 2: 

"Security is that condition, which guarantees the protection 
of classified information from either accidential or unauthorized 
intentional disclosure, modification or destruction and ex¬ 
cludes ANY INJURY TO THE SYSTEM BY ELEMENTS ENDANGERING ITS 
SECURITY". 

To REACH THIS CONDITION, A WELL BALANCED SET OF SECURITY 
MEASURES HAS TO BE DEVELOPPED IN THE AREAS OF 

- PERSONNEL SECURITY 

- PHYSICAL SECURITY 

- ADMINISTRATIVE SECURITY 

- COMMUNICATIONS SECURITY AND LAST BUT NOT LEAST 

- ADP-SECURITY 

For THE DISCUSSION TO FOLLOW, I WILL CONCENTRATE ON ADP-SECURITY 
AND ONLY MENTION SHORTLY THE REQUIREMENTS FOR COMMUNICATIONS 
SECURITY. 

The EIFEL 2 ADP-security requirements are based on the following 

INPUTS: 

- AN EVALUATION OF THE POTENTIAL THREATS TO THE SYSTEM 

- AN EVALUATION OF THE OPERATIONAL REQUIREMENTS AND THEIR 

SECURITY IMPACT 

- THE EXPERIENCE WITH OUR TESTSYSTEMS EIFEL 1 AND DISTEL 1 

- AN EVALUATION OF THE EXISTING SECURITY AND PRIVACY REGULATIONS 

The formulation of the security requirements has been influenced 












VERY MUCH BY THE WORK DONE BY OUR ADVISORY GROUP IAB6 AND 
BY THE USAF/ESD ACTIVITIES(AS FAR AS PUBLISHED IN THE OPEN 
LITERATURE). 

A) Th£ THREAT 

AS YOU CAN IMAGINE, MOST OF THE DATA WHICH WILL BE STORED, 
PROCESSED AND DISTRIBUTED IN EIFEL 2 ARE HIGHLY SENSITIVE 
AND VITAL FOR NATIONAL COMMAND AUTHORITIES AS WELL AS FOR 

NATO. Therefore it is certain, that EIFEL 2, respective its 

COMPONENTS, WILL BE A HIGH PRIORITY TARGET FOR ESPIONAGE 
AND FOR SABOTAGE, BOTH IN PEACETIME AS WELL AS IN WAR AND 
WILL BE SUBJECT TO ALL THE WELL-KNOWN THREATS OF ADP-SYSTEMS 
LIKE 

- THEFT 

- FORGING OF DATA 

- ERASURE OF DATA 

- UNAUTHORIZED USE OF SYSTEM RESOURCES 

- INTERCEPTION OF RADIATION FROM COMPUTERS, LINES AND 
TERMINALS 

- TAPPING OF COMMUNICATION LINES 

- CROSSTALK AND Ml SHOUTING 

- JAMMING 

But COMPARED TO CONVENTIONAL ADP-SYSTEMS THE THREAT POTENTIAL 
FOR EIFEL 2 IS GREATLY ENLARGED THROUGH TWO FACTORS: 

- ITS ARCHITECTURAL CHARACTERISTICS LIKE 

+ DECENTRALIZED PROCESSING WITH AN EVEN MORE DECENTRALIZED 
USER POPULATION OF APPROXIMATELY AOOO USERS AT 15o 
DIFFERENT LOCATIONS IN THE FEDERAL REPUBLIC OF GERMANY 


+ DISTRIBUTED DATABASE 










+ PACKET-SWITCHED NETWORK 


- OUR GEOPOLITICAL SITUATION, WHICH IS CHARACTERIZED BY 
+ A CLOSE PROXIMITY TO THE WARSHAW PACT COUNTRIES 


+ A SUPPOSEDLY GREAT NUMBER OF UNDERCOVER AGENTS, WELL 
TRAINED FOR ESPIONAGE AND SABOTAGE 

The impact, these factors have on -the reliable and secure 

OPERATION OF EIFEL 2 JUSTIFIES IN OUR OPINION THE HIGH 
PRIORITY THAT ADP-SECURITY HAS IN OUR WORK, 

b) Operational .reau isam 

Before talking about the operational requirements and their 

IMPACT ON ADP-SECURITY, IT HAS TO BE DETERMINED 

- WHICH ARE THE MOST VALUABLE AND CRITICAL RESOURCES OF THE 
SYSTEM WHICH HAVE TO BE PROTECTED THROUGH ADP-SECURITY 
MEASURES AND 

- WHAT IS THE REQUIRED GRANULARITY OF PROTECTION 

In a CCIS like EIFEL 2 which has to support military com¬ 
manders in all phases of the command and control process, 
the data has the highest value for the user. Therefore it 

HAS TO BE PROTECTED 

- AGAINST UNAUTHORIZED AND ACCIDENTAL OBSERVATION TO 
GUARANTEE ITS SECRECY AND 

- AGAINST UNAUTHORIZED AND ACCIDENTAL MODIFICATION AND 
DESTRUCTION TO RETAIN ITS INITIAL INTEGRITY OR SOUNDNESS 
THROUGHOUT THE OPERATION OF THE SYSTEM, 

There is no discussion, that the hardware of the system has 







TO BE PROTECTED TOO, BUT THE NECESSARY PROTECTION MECHANISMS 


ARE MAINLY A PART OF THE PROTECTION THROUGH PHYSICAL MEASURES 
AND NOT PART OF ADP-SECURITY AS DISCUSSED IN THIS PRESENTATION. 

Because EIFEL 2 will be used primarily in an interactive 

MODE WITH A DIALOGUE-LANGUAGE, THE GRANULARITY OF PROTECTION 
SHOULD GO DOWN TO THE DATA-ITEM LEVEL. 

NOW, IF WE LOOK AT THE LIST OF OPERATIONAL REQUIREMENTS FOR 
EIFEL 2, THREE OF THEM HAVE A VERY STRONG IMPACT ON THE 
ADP-SECURITY FUNCTIONS OF THE SYSTEM: 

- AVAILABILITY 

- TIMELINESS AND 

- USER ACCEPTANCE 

(1) Availability 

The main thrust for the security requirements comes from 

THE OPERATIONAL REQUIREMENT TO PROVIDE A SECURE AND CON¬ 
TINUOUS SERVICE 24 HOURS A DAY/ 7 DAYS A WEEK. As A CON¬ 
SEQUENCE IT MUST BE POSSIBLE 

- TO PROCESS DATA, PROGRAMS AND SUBSYSTEMS OF ALL SECURITY 
CLASSIFICATIONS/CATEGORIES SIMULTANEOUSLY 

- TO SERVE USERS WITH DIFFERENT SECURITY CLEARANCES 
SIMULTANEOUSLY 

- TO UPDATE DATA ITEMS WITH DIFFERENT SECURITY CLASSIFI- 
CATIONS/CATEGORIES SIMULTANEOUSLY IF A CHANGE IN THE 
REAL WORLD HAS OCCURED. 

This requires a system, which allows the simultaneous 

STORGAE AND PROCESSING OF DATA WITH DIFFERENT CLASSIFI" 
CATIONS/CATEGORIES AND THE MANIPULATION OF THESE DATA 
FROM REMOTE TERMINALS BY USERS HAVING DIFFERENT SECURITY 








CLEARANCES. 

An operating mode like " dedicated processing" is not 
ACCEPTABLE IN EIFEL 2 FOR OPERATIONAL REASONS. 

(2) Timeliness 

The value of a CCIS depends largely on the timeliness 
of the data it contains. In EIFEL 2 we have the philo¬ 
sophy OF THE "EVENT-ORIENTED" UPDATE. THIS MEANS/ THAT 
EACH TIME SOME STATUS IN THE REAL WORLD CHANGES/ THERE 
HAS TO BE AN IMMEDIATE UPDATE OF THE RESPECTIVE ENTRY 
IN THE DATABASE. 

Because such a situation can happen to different data 

OF DIFFERENT SECURITY CLASSIFICATION/CATEGORIES SIMUL¬ 
TANEOUSLY/ THERE AGAIN A MODE OF OPERATION LIKE "DEDI¬ 
CATED PROCESSING" IS NOT ACCEPTABLE. 

(3) User.acceptance 

One of the key factors for the acceptance of the system 

BY THE USER IS THE "EASE OF USE". 

Ease of use from a security point of view requires that 

MECHANISMS WHICH ARE USED TO ENFORCE SECURITY MUST BE 
DESIGNED IN SUCH A WAY/ THAT THEY DO NOT OVERBURDEN THE 

user. Otherwise there will be the danger, that the 

SECURITY MECHANISMS WILL BE IGNORED OR CIRCUMVENTED. 

(Example: a too sophisticated password procedure). 

The ORGANIZATIONAL INCONVENIENCIES FOR THE USER SHOULD 
BE KEPT AT A MINIMUM. FOR EXAMPLE, IT SHOULD NOT BE 
NECESSARY TO CLEAR USERS FOR OTHER CLASSIFICATIONS/ 
CATEGORIES THAN THEY NEED FOR THEIR WORK. 
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Therefore a mode of operation like "system high" is not 

ACCEPTABLE. 

By the way, there are additional arguments against a 
"system high" mode of operation. 

First, the cost to clear more people for higher security 
classification than necessary and second the violation 

OF THE PRINCIPLE OF "LEAST PRIVILEGE". 

Experience, with EIFEL 1 and DISTEL 1 

When we started with the development of both systems as 

TESTSYSTEMS IN THE LATE SIXTIES, ADP-SECURITY WAS NOT A 
PRIMARY DESIGN GOAL, NEVERTHELESS THERE ARE SOME SECURITY 
FEATURES - ACCORDING TO THE THEN AVAILABLE STATE OF THE 
ART - WHICH PROOFED TO BE VERY EFFICIENT, ESPECIALLY IN THE 
AREAS OF IDENTIFICATION, AUTHENTICATION AND AUTHORIZATION, 

But THE MAIN EXPERIENCE WE GAINED WAS NOT IN THE AREA OF 
ADP-SECURITY BUT IN THE AREAS OF PERSONNEL-, PHYSICAL-, 
ORGANIZATIONAL- AND COMMUNICATIONS SECURITY. 

Security and., privacy-BE auiAimi 

Basis for most part of the security requirements, which will 

BE DISCUSSED NOW, ARE THE EXISTING SECURITY REGULATIONS OF THE 

German Forces and the privacy law of the Federal Republic of 
Germany. 

The ADP-security requirements can be associated to two 
categories, 

- general requirements and 

- special requirements 


From a users point of view, there are 5 general requirements 





WHICH WE THINK ARE ESSENTIAL WHEN TRYING TO PROTECT 
CLASS IFIED/CATEGORI ZED INFORMATI ON: 


A CLEAR DEFINITION OF THE LEVELS OF PROTECTION 

EIFEL 2 MUST BE CAPABLE TO PROTECT DATA - ITEMS/ 

DATA-FILES WHICH HAVE DIFFERENT SECURITY CLASSIFICATIONS/ 
CATEGORIES WHEREBY ONE RECORD CAN CONTAIN DATA"ITEMS OF 
DIFFERENT SECURITY CLASSIFICATIONS. 

The security classifications range from "restricted" to 

"COSMIC TOP SECRET"/ EXAMPLES OF CATEGORIES TO BE HANDELD 

in EIFEL 2 are "NATO" or "CRYPTO". The full scope of 

CATEGORIES IS NOT YET FINALLY DETERMINED. 

- A-D.EF.INIXL Q t L flE... U iL.ACCE.SS R OLLS. 

The BASIS FOR access permission is the established NEED-TO- 
KNOW OF A USER OR HIS PRINCIPAL IN THE SYSTEM DERIVED FROM 
HIS OPERATIONA' TASKS. 

A USER/ A PROGRAM OR A SYSTEM RESOURCE SHALL BE GRANTED 
ACCESS ONLY TO THAT CLASSIFIED/CATEGORIZED INFORMATION 
FOR WHICH HE HAS AN ESTABLISHED NEED-TO-KNOW AND THE 
APPROPRIATE ACCESS AUTHORIZATION. The DEFAULT SITUATION 
SHALL BE LACK OF ACCESS. 

ADHERENCE TQ . ..THE PR INCIPLE QF LEAS T PR I V ILEGE 
IN THE ORGANIZATIONAL ENVIRONMENT OF EIFEL 2 AS WELL AS IN 
THE ADP-SYSTEM, THE PRINCIPLE OF LEAST PRIVILEGE MUST BE 
ADHERED TO. A USER/ A PROGRAM OR A SYSTEM RESOURCE SHALL 
BE GRANTED ONLY THE SMALLEST POSSIBLE SET OF PRIVILEGES 
NECESSARY TO PERFORM ITS TASK. 









TO COMPLY WITH OUR SECURITY REGULATIONS AND TO ALLOW THF. 
DETECTION OF BREACHES OF SECURITY/ IT IS NECESSARY TO HAVE 
MECHANISMS TO TRACE THE ACTIONS OF THE USERS IN THE SYSTEM. 

This requires, that every user who is working with classi¬ 
fied/categorized INFORMATION MUST BE MADE ACCOUNTABLE FOR 
HIS ACTIONS IN THE SYSTEM. 

- CONTINUITY OF OPERATION OF THE SECURITY MECHANISMS 

The COMPONENTS OF THE SYSTEM, WHICH FULFILL SECURITY 
FUNCTIONS MUST BE SWITCHED ON CONTINUOUSLY, THEY MUST BE 
CAPABLE OF SURVIVING ATTACKS AGAINST THEM.THE SECURE 
OPERATION OF THE SYSTEM AND ITS SECURITY MECHANISMS MUST 
BE DEMONSTRATED BY THE SYSTEM ITSELF BOTH AT REGULAR 
INTERVALS AND BY SPOT CHECKS. 

NOW, LET ME DESCRIBE OUR SPECIAL SECURITY REQUIREMENTS: 

- CHANGE OF CLASSIFICATION/CATEGORY 

Security classifications and categories are assigned to 

DATA-ITEMS, DATA-RECORDS AND DATA-FILES WHEN THEY ARE FIRST 
BROUGHT INTO THE SYSTEM. It IS REQUIRED, THAT ONLY AUTHO¬ 
RIZED PERSONNEL CAN CHANGE OR DELETE THEM, THIS AT ANY 
TIME WITHOUT INTERRUPTING THE OPERATION OF THE SYSTEM. 

Every change or deletion must be documented by the system. 

- MARKING OF STORAGE- AND OUTPUT MEDIA 

+ STORAGE MEDIA MUST BE MARKED IN ACCORDANCE WITH THE 
SECURITY REGULATIONS, THE MARKING MUST BE ALSO READABLE 
BY THE SYSTEM; 


+ LISTS, TABLES OR GRAPHIC DISPLAYS, WHICH ARE TO BE 








PRINTED OUT BY THE SYSTEM/ MUST BE MARKED AUTOMATICALLY 
BY THE SYSTEM. ADDITIONALLY/ THE SYSTEM MUST ATTACH AN 
UNAMBIGUOUS REGISTRATION NUMBER TO EVERY PRINTOUT; 

+ OUTPUTS ON DATA DISPLAY UNITS OR LARGE SCREEN DISPLAYS 
MUST BE MARKED BY THE SYSTEM AUTOMATICALLY WITH THE 
APPROPRIATE SECURITY CLASSIFICATION/CATEGORY. 

“ LOG-ON 

Prior to get access to the system and to the classified/ 

CATEGORIZED INFORMATION/ A USER MUST GO THROUGH THE 

FOLLOWING STEPS: 

+ Identification 
+ Authentication 
+ Autorization 

There are some additional requirements/ which characterize 

THE LOG-ON FUNCTION: 

+ THE NUMBER OF ATTEMPTS TO GET A LOG-ON FROM A TERMINAL 
MUST BE LIMITABLE IN NUMBER AND TIME. ATTEMPTS EXCEEDING 
THOSE PREDEFINED LIMITS MUST BE RECOGNIZED BY THE SYSTEM 
AND BROUGHT FORWARD TO A SECURITY OFFICER FOR FOLLOW-ON 
ACTIONS; 

+ BEFORE A USER PUTS CLASSIFIED/CATEGORIZED INFORMATION 
INTO THE SYSTEM BY MEANS OF HIS TERMINAL AND THROUGH THE 
NETWORK/ THE ADRESSED COMPUTER OR THE ADRESSED DATABASE 
M UST IDENTIFY ITSELF TO HIM; 

+ AFTER A SUCCESSFUL START OF A DIALOGUE/ THE SYSTEM IS 
REQUIRED TO CHECK THE USERS AUTHORIZATION FOR ACCESS IN 
INTERVALS WHERE TIME AND SEQUENCE OF THE CHECKS ARE NOT 
PREDETERM INABLE BY THE USER; 






STORAGE OF DATA AND PROGRAMS 

The system must be designed in a way that it has the 

DEMONSTRABLE CAPABILITY OF ENSURING THAT 
+ INFORMATION CLASSIFIED AS "COSMIC TOP SECRET" IS STORED 
SEPARATELY FROM INFORMATION OF OTHER CLASSIFICATION; 

+ NO USER OR PROGRAM MAY COME INTO A POSITION TO GAIN UN¬ 
AUTHORIZED INSIGHT OF OR ACCESS TO ANOTHER USERS 
CLASSIFIED INFORMATION AND 

+ NO USER OR PROGRAM MAY COME INTO A POSITION TO MANIPU¬ 
LATE THE CLASSIFIED INFORMATION OR PROGRAM OF ANOTHER 
USER. 

Information and software/ necessary for the implementation 

OF SECURITY MEASURES IN THE SYSTEM MUST BE STORED IN SUCH 
A WAY THAT THEY CAN DEFINITELY NOT BE READ/ CHANGED OR 
ERASED BY OTHERS THAN THOSE RESPONSIBLE FOR SECURITY MATTERS. 

PR OCESSING. OF DATA 

The system must ensure/ that a not-predetermined mix of 

DATA OF ALL SECURITY CLASS IFICATIONS/CATEGORIES CAN BE 

PROCESSED SIMULTANEOUSLY. To PREVENT SECURITY VIOLATIONS IT 

MUST BE DEMONSTRATED THAT 

+ THE SINGLE SECURITY PROPERTY AND 

+ THE * PROPERTY 

CAN BE GUARANTEED BY THE SYSTEM. 

If EXTRACTS FROM DATA-FILES ARE REQUIRED AND SUCH EXTRACTS 
MAY RECEIVE A LOWER SECURITY CLASSIFICATION THAN THE ORIGINAL 
DATA-FILE/ SPECIAL SECURITY MEASURES MUST BE TAKEN TO DOWN¬ 
GRADE THE DATA IN A TRUSTABLE MANNER. 
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ADMINISTRATION OF DATA 

The system must support the administration of classified/ 

CATEGORIZED INFORMATION STORED/ PROCESSED AND DISTRIBUTED 
IN THE SYSTEM BY LOGGING 
+ ALL INPUTS 

+ ALL STATES OF INTERNAL PROCESSING(ACCESSES/ CHANGES ETC) 

+ ALL OUTPUTS 

QUIEU1 

Prior to passing classified/categorized information to an 

OUTPUT UNIT/ THE SYSTEM MOST 

+ POSITIVELY IDENTIFY THE USER AND THE OUTPUT UNIT IN¬ 
VOLVED 

+ MAKE SURE THAT THE OUTPUT UNIT IS AUTHORIZED TO RECEIVE 
THAT OUTPUT, 

The OUTPUT OF CLASS IFIED/CATEdORIZED INFORMATION TO UN¬ 
MANNED TERMINALS IS NOT PERMITTED. 

AUDlimG-AMD SURVEILLANCE 

+ ALL INFORMATION REQUIRED TO MONITOR SECURITY MUST BE DIS¬ 
PLAYED TO THE SECURITY OFFICER ON A SEPARATE TERMINAL; 

+ THE SECURITY OFFICER MUST HAVE THE MECHANISMS TO 

- MONITOR THE ONGOING ACTIVITIES OF ALL TERMINALS 

- MONITOR THE ONGOING ACTIVITIES IN THE DATABASE 

- MONITOR THE HARDWARE; 

+ THE SECURITY OFFICER MUST BE ABLE AT ANY TIME TO DENY 
USERS AND TERMINALS, EITHER SINGLY OR IN GROUPS, ACCESS 
TO THE SYSTEM AND TO THE DATA; 

+ THE SYSTEM MUST HAVE THE MECHANISMS THAT USERS OR TER¬ 
MINALS, EITHER SINGLY OR IN GROUPS, CAN BE SWITCHED OFF 


K-16 










AT ANY TIME BY THE SECURITY OFFICER; 

+ FOR AUDITING PURPOSES/ THE FOLLOWING DATA SHOULD BE 
LOGGED! 

- EVERY ACCESS TO CLASSIFIED/CATEGORIZED INFORMATION, 

- EVERY MANIPULATION WITH SUCH INFORMATION, 

- EVERY LOG-ON OPERATION WHETHER SUCCESSFUL OR NOT, 

- EVERY LOG-OFF OPERATION, 

- EVERY CHANGE OF ACCESS PARAMETERS AND CLASSIFICATIONS/ 
CATEGORIES 

PROTECTION OF TECHNICAL COMPONENTS 

+ THE SYSTEM MUST ENSURE, THAT NO USER IS ABLE WITHOUT 
AUTORIZATION, TO DENY OR INTERRUPT THE SERVICES TO AN¬ 
OTHER user; 

+ THE SECURITY MECHANISMS OF THE SYSTEM SHOULD BE DESIGNED 
IN SUCH A WAY THAT THEY CANNOT BE BROKEN OR CIRCUMVENTED 
EVEN IF A PENETRATOR KNOWS HOW THEY WORK; 

+ THE SYSTEM MUST AUTOMATICALLY BREAK CONNECTION WITH A 
TERMINAL IF 

- THE TERMINAL IS SWITCHED OFF, 

- THE POWER SUPPLY OF THE TERMINAL BREAKS DOWN, 

- THE COMMUNICATION LINE BREAKS DOWN, 

- WHEN, AFTER A SUCCESSFUL LOG-ON, THE TERMINAL RESTS 
UNUSED FOR A PREDETERMINED TIMEPERIOD, 

- THE CRYPTOGRAPHIC EQUIPMENT GOES OUT OF OPERATION, 

- THE NUMBER OF UNSUCCESSFUL LOG-ONS FROM A TERMINAL EX¬ 
CEEDS A PREDETERMINED LIMIT, 

+ IF NECESSARY, A PROCEDURE FOR TERMINATION OF THE DIALOGUE 
MUST ERASE ANY CLASSIFIED/CATEGORIZED INFORMATION THAT 
MAY BE AVAILABLE IN THE USER TERMINAL, 

+ ALL DEVICES AND COMMUNICATION LINKS MUST BE DESIGNED 
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IN A WAV THAT THEY 


+ DO NOT EMIT INFORMATION OF A COMPREHENSIBLE NATURE 
+ ARE INSENSITIVE TO JAMMING, 

NOW LET ME FINISH THE LISTING OF ADP-SECURITY REQUIREMENTS 
AND LET ME ADD SOME REQUIREMENTS FROM THE COMMUNICATION 
SECURITY AREA. 

- TRANSMISSION OF CLASSIFIED INFORMATION MUST BE EITER EN¬ 
CIPHERED OR - WHERE PERMISSABLE - THROUGH APPROVED CIRCUITS; 

- THE FLOW OF INFORMATION OVER THE COMMUNICATION LINES MUST 
NOT ALLOW ANY INFERENCE ON THE TRUE NATURE OF THE TRAFFIC 
ON THE LINE- 1 

- No CLASSIFIED INFORMATION MAY APPEAR IN CLEAR LANGUAGE IN 
THE SWITCHING CENTERS; 

- EVERYCOMPUTER IN THE SYSTEM MUST VERIFY THE AUTHORIZATION 
OF A USER ON ITS OWN INSTEAD OF RELYING ON THE VERIFICATION 
MADE BY ANOTHER COMPUTER. 

I GAVE YOU A PRESENTATION OF THE ADP-SECURITY REQUIREMENTS FOR 
EIFEL 2. I MUST ADMIT. THAT THIS IS A RATHER PRETENTIOUS CA¬ 
TALOGUE OF REQUIREMENTS. WHEN WE DEVELOPED THIS CATALOGUE BEFORE 
THE BEGINNING OF THE CONCEPTUAL PHASE OF EIFEL 2, OUR MAIN GOAL 
WAS TO GIVE INDUSTRY A BASIS TO REALIZE MOST OF THE REQUIREMENTS 
THROUGH TECHNICAL MEASURES IN ORDER TO KEEP MEASURES IN THE 
AREAS OF PERSONNEL. INFRASTRUCTURE AND ORGANIZATION LOW. 

NOW AT THE END OF THE CONCEPTUAL PHASE HOWEVER. WE FIND THAT 
THERE ARE PROBLEMS IN THE TECHNICAL AREA WHICH WILL FORCE US - 
AT LEAST IN THE FIRST STAGE OF EIFEL 2 - TO REALIZE SEVERAL OF 
THOSE REQUIREMENTS THROUGH PERSONNEL, PHYSICAL AND ORGANIZATIONAL 
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MEASURES. 


We hope that a risk-assessment we will start at the beginning 

OF THIS YEAR WILL LEAD US TO A WELL BALANCED SECURITY CONCEPT 
FOR EIFEL 2 IN THE FIRST STAGE AND FOR THE STAGES TO FOLLOW. 


Thank you. 
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UNCLASSIFIED 


| IwRiOstKdo 



wm 


E 1 FEL 

UNCLASSIFI 

■M 

i 


Stand: 

AbtlnfoVerarbLw 

GAF-CCIS PHILOSOPHY 


























LwFuDstKdo 



EIFEL 


UNCLASSIFIED 


FUNCTIONS 



0 COLLECTION. STORAGE. DISTRIBUTION AND DISPLAY OF 
STATUS INFORMATION 

0 REPORTING SYSTEM FOR ALL GAF - UNITS 


0 DISTRIBUTION OF ORDERS AND MESSAGES 


0 DECISION AIDS 

0 COMMON DATABASE FOR ALL SUBSYSTEMS 
0 PROCESSING CAPABILITIES FOR ALL SUBSYSTEMS 


0 INTERFACE TO NATIONAL AND NATO SYSTEMS 
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A btlnfoVerarbLw 



1 FEL 

UNCLASSIFIED 

GAF CCIS 

Stand: 


BASIC SYSTEM 

o EIFEL 

SUPPORTS THE COMMAND AND CONTROL PROCESS IN THE GAF BY 
PROVIDING BASIC DATAPROCESSING FUNCTIONS AND DATA IN 
ALL PHASES TO USERS AND SUBSYSTEMS 

SUBSYSTEMS 

o DISTEL 

SUPPORTS THE MISSION PLANNING PHASE FOR OFFENSIVE 
A3R - FORCES BY PROVIDING SPECIAL APPLICATION FUNCTIONS 

o SYLT 

SUPPORTS THE MISSION PLANNING PHASE FOR TACTICAL AIR-LIFT 
FORCES BY PROVIDING SPECIAL APPLICATION FUNCTIONS 

o SUSYLOG 


SUPPORTS THE MISSION PLANNING PHASE FOR LOGISTIC FORCES 
BY PROVIDING SPECIAL APPLICATION FUNCTIONS 
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I 
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E 1 FEL 


UT] 

w 

AbtlnfoVerart 


UNCLASSIFIED 

"iLw 

ARCHITECTURAL CHARACTERISTICS 

Stand 


DECENTRALIZED 

PROCESSING 

DISTRIBUTED 

DATABASE 


PACKET SWITCHED 
NETWORK 
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E 1 F~ C L 

UNCLASSIFIED 

W 



Stand 

x — 

THREAT EXAMPLES 


Abtlnfo VerarbLw 




0 THEFT 

. 0 FORGING OF DATA 

0 ERASURE OF DATA 

0 UNAUTHORIZED USE OF SYSTEM RESOURCES 

0 INTERCEPTION OF RADIATION 

0 TAPPING OF COMMUNICATION LINES 
0 CROSSTALK / MISROUTIMG 


0 JAMMING 
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E IFEL 


UNCLASSIFIED 


AbtlnfoVerarbLw 


OPERATIONAL REQUIREMENTS 


0 

AVAILABILITY 

0 

SURVIVABILITY 

0 

AUTONOMOUS MODE OF OPERATION 

0 

TIMELINESS 

0 

SECURITY 

0 

FLEXIBILITY 

0 

MOBILITY 

0 

USER ACCEPTANCE 
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Security Requirements, Design, 
and the Use of Trusted Software 
in a High Integrity Commercial Network 


Dr. Thomas A. Berson 
SYTEK, fnc. 
Sunnyvale, CA 


SYTEK EXPERIENCE WITH TRUSTED SYSTEMS 

• MITRE Kernel I, II 

• MULTICS, GUARDIAN 

• SCOMP 

• SATIN IV, SACDIN 

• KSOS 

• PSOS 

• TACEXEC 

• Other special programs 
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II 
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NETWORK CHARACTERIZATION 

• Commercial, value added 

• TDM, TDMA channels 

• Packet switched 

SECURITY MOTIVATION 

1 . Network self protection 

2. Subscriber data protection 

3. Government regulations (e.g. NSC-24) 

SECURITY POLICY 

“The network shall not misdeliver messages” 


VULNERABILITIES & COUNTERMEASURES 

• Design and implementation errors 

Trusted software—isolation and construction 

• Active and passive channel tapping 

Link encryption 

• Alteration of network environment 

Physical and personnel security 

• Theft of network services 

Access control—authentication and authorization 







TECHNIQUES FOR INCREASING CONFIDENCE 
IN SOFTWARE 


ABCDEF 

CDEF 

DEF 

BCDEF 

DEF 

CDEF 

EF 

BCDEF 

BCDEF 

CDEF 

F 

BCDEF 

CDEF 


1 . 


2 . 


Personnel integrity 
Configuration control 
Formal statement of reliability criteria 
Careful hierarchical design 
Formal mathematical specification of design 
Peer and management inspection of design 
Proof that design conforms to desired criteria 
Choice of appropriate programming language 
Careful implementation of (proven) design 
Peer and management review of implementation 
Proof that implementation conforms to (proven) 
design 

Testing of system 
Controlled maintenance 


CONCLUSION 

Trusted software techniques can contribute 
to contemporary system design and construction. 

More data is needed on the costs and benefits 
of trusted software techniques. 
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CURRENT STATUS OF COMPUTER SECUR ITY ACTIVITIES IN GERMANY 

AND 

RESULTS OF AN EVALUATION OF SPECIAL, KSOS, AND PSOS 


Dr. Hans vor der Bruck 

Industrieanlagen- Betriebsgesellschaft mbH ( IABG ) 
Ottobrunn b. Munich 












Current status of the security research 
and development in the Federal Republic 
of Germany 


Requirements: 

Requirements of the German Air Force 
Requirements by the german privacy act 

# S ecure Identification 

# Secure Authorisation 

# Unforgeable Access Control 

# Secure Protocol Functions 

# Secure Data Transmission 
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Current projects 


Universities: 

Karlsruhe: 


Berlin: 


Stuttgart: 


Investigations on abstract 
models 

Implementation of a System 
without formal Specifications, 
but with Security as a main 
design goal 

Formal Specifications of the 
protocols of the ISO Reference 
Model (Extension of Special) 

Two other groups are working 
on Specification Languages 

EPOS: A Specification and Design 
Technique for Real-time automation 











Current projects 


S1EMENS 

Decision to build an operating system with security 
as one of its basic design issues. 

The concept phase has started 

Nothing is known about the underlying philosophy 


IABG 

Since 1976 investigations in the area of 

computer security 

Lecturing problem awareness 

Penetrations of EDP-Systems 

Evaluation of security and audit software packages 

Monitoring status, progress and trends of 

computer security 

Technical advice in computer and communications 
security technology 

Development of requirements for the hardware 
and the software structure 
Proposals for the security concept of EIFEL II 
Investigations of Special and the Specifications 
of KSOS and PSOS 









SPEC IAL 


Advantages: 

Formal specifications are an important step 
to provable secure systems 

A Special specification is relatively easy to convert 
into a program 

Special is relatively easy to learn 
Nonprocedural specification 
Strong typing 
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SPECIAL 


Desirable Modifications and Improvements 

Clear definition of the relationship between the 
exceptions and effects 

Possibility to change V-functions only in the module 
in which they are defined 

Possibility of an exceptions-paragraph in hidden 
functions 

Expressions for the definition of sequencing and 
time conditions 


H idden 0- and OV-functions 









Some results of the KSOS and PSOS 
investigations 


The aim of the investigations was: 

To get some experience with Special specifications and 
the power of the tools. 

Results: 

a) Formal mistakes, which had to be found by the 
described tools: 

PSOS 

* Hidden functions are referenced in other 
than their defining moduls 

* The Exceptions-part of V-, 0- and OV- 
functions is frequently omitted 

* There are inconsistencies between the 
interface definitions and the references 
made from modules of a higher level 

to functions of a lower level 


M-7 





Formal mistakes, which had to be found by the 
described tools: 


KSOS 

* There are inconsistencies between the 
EXTERNALREFS paragraph of the module KER 
and the modules in which the types and 
functions are defined. 

* The EXCEPTIONS part of V-, 0- and OV- 
functions is often omitted 

x Hidden V-functionsare referenced in other 
than the defining module 

* Variables of different types were equated or 
functions are called with parameters of the 
wrong type 
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Mistakes in the specifications, which couldn't be found 
by the tools: 


PSOS: 


x In some functions the examination of the 
exception conditions is incomplete 

x At creation time the user gets a wrong security 
level 

x Loop indices are wrong at many places. 

At least one of these mistakes is critical 
to security 

x Functions are called with wrong parameters 
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Mistakes in the specifications, which couldn't be found 
by the tools: 


KSOS: 

-x Inconsistencies between the verbal and the 
formal specifications 

* The function for the examination of the 
security rules is wrong 

* Sometimes functions are called with wrong 
parameters 


* Some important examinations of exception 
conditions are omitted 










Our conclusions: 


* Formal specifications should be used for the 
development of secure operating systems 

x Special with some changes seems to be a proper 
tool 

* The tools for Special have to be improved 

* A formal specification with tools for the checking 
of the syntactical and some semantical properties 
does not guarantee a correct specification 

* Until more advanced and sophisticated tools become 
available, we have more confidence in systems based 
on a security kernel than in systems like PSOS 
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The Trusted Computing Base 

P. S. TASKER 
THE MITRE CORPORATION 



Plan of Talk 


TCBs and operating systems 
Defining the protection policy 
Developing TCB software 
TCB function & structure 
I valuation Implications 


How Does a TCB Relate 
to an Operating System? 


Operating system basis 

Supervisory and control services 
Extended machine 
Protection environment 


Policy 

Mechanism 











Reference Monitor Concept 


l- 

| SUBJECT 


REFERENCE 

MONITOR 


—- 

OBJECT 


— 


I 

) 


ACCESS RULES 


GOALS. 

COMPLETENESS 

ISOLATION 

VERIFIABILITY 


Computer System Organization 


PROCESS BOUNDARY 




HUMAN 

EDITOR COMPILER „ U ^Efl _ 

OTHER 

interface 

APPLICATION, 

utilities 




SVC 

INTERFACE 

OPERATING SYSTEM 



HARDWARE 

HARDWARE 


INTERFACE 


PER-PROCESS VIRTUALIZATION 




















Computer System Organization 
in Terms of a TCB 


PROCESSBOUNOARY 


t 


USER SOFTWARE 

_ 1 _*_ 1 

OS 

UTILITIES 

TCB 

UTILITIES 

| 

OS SOFTWARE NOT PROTECTION 

_ 1 _ 1 _ 1 

RELATED 



HUMAN 

INTERFACE 


OS SVC 
INTERFACE 


TCB SVC 
INTERFACE 


TCB 


HARDWARE 


SCOPE OF FUNCTIONALITY 
EXCLUDES NON ESSENTIALS 
COMPONENTS 

HARDWARE ANO SOFTWARE 


Hardware Support 


Memory protection 
Virtual memory 
Tagged memory 
Process control 

1 O 

Privileged states/domains 


Three-Domain System 


USER SOFTWARE 


! OS TCB , 

, UTILITIES UTILITIES 

-4--i 


OS SOFTWARE NOT PROTECTION RELATED 


i.. 1._ 


USER 

DOMAIN 


SUPERVISOR 

DOMAIN 


TCB 


KERNEL 

DOMAIN 


HARDWARE 



























Integrity Policy 


Protection against unauthorized modification 


Directly related to security 










Policy Enforcement Strategy 


Focus on security policy 

Access control — protects containers 

Flow control — protects contents of the containers 


Access Control Model — Access Matrix 



OBJECTS 

O2 O3 • •« On 

x x 

X 

X X 


X 

\ 

RWE 


Example of a Set 
Theoretical How 











Example of a Linear X Set 
Lattice—Military Policy 














Plan of Talk 


TCBs and Operating Systems 
Defining the protection policy 
TCB function & structure 
Evaluation implications 


TCB Functions 


Establish a secure state 


C ontrof state transitions 

Hind secure system to external environment 


Establish a Secure State 


Program Loaders 

Initialization 
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Control State Transitions 


Processes 

Create/delete 
Swap 

bend receive 1PC message 
Get set status 
Storage 
Create, delete 

Grant revoke ownership/access 
Read write data 
Get set status 
l O 

Create delete 

Grant revoke ownership access 
Read write device 
Get set status 


Bind Secure System to 
External Environment 


Operations interface 
Device configuration control 
Extension of policy 
Facility dependent services 
User space definition 
Secure user interface 

Preservation of ecure state across discontinuities 


Properties Of Trusted Software 


Mav enforce a protection police 


Mav deliberately, selectively override policy 
implemented l»v other crusted software 

Mav perform functions that could indirectlv 
enable a policy to he violated 











Kemelized System 


PROCESS BOUNDARY 

| < r _ 

OS TRUSTED 

USER SOFTWARE UTILITIES PROCESSES 


OS SOFTWARE NOT PROTECTION RELATED 


HUMAN 

INTERFACE 


OS SVC 
INTERFACE 


KERNEL SVC 
INTERFACE 


HARDWARE 


Formal Specification in Software 
Development 


Functional 

Requin’ 

fTW>IS 

— 



Proteciion 

Model 


MoiUjh- 
SP*'. «, 



(S 


Summary 


TCBs and operating systems 

Provides a verifiable protection base for an operating system 

Defining a protection policy 

Acts according to a precisely stated protection policy 

TCB functions & structure 

Carries out certain relevant operating system functions 
Designed in methodical steps 

May be organized as \ kernel and other trusted software 


















Evaluation Implications 


TCB Specification: 


Generic mechanism 


( description 
requirements 


Evaluation Criteria: 

Policy options 

Mechanism features 

Construction environment (assurance) 


-- 

Levels off TCB Protection 

0 No protection 
1 Limited controlled sharing 

2. Extensive mandatory sharing 

3. Structured protection mechanism 

4. Design correspondence 

5. implementation correspondence 

6. Object code analysis 

'v.___ 


Documents Provide Focus 



• Proposal 


• Source selection 


• (».P. pmduct 


development 
consistent assessment 
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PROCEEDINGS OF THE SEMINAR ON THE DOD COMPUTER SECURITY INIT1AT—ETC(U) 
1900 

NL 


3 or 3 

















































Three-Domain System 


OS SOFTWARE MOt RROTECTIO* RELATEO 

TCS 

HAROWARE 


Plan of Talk 


TCBa and opera ling tyiitmi 
Defining the protection policy 
Distinguishing feature* 
Model* 

Developing the TCB software 


Denial of Service Policy 


Protection again*! unauthorlted dtaruption of service due to: 
Delay 
Crash 

Consumption of renource* 

Destruction of Information 
Masquerading information 
Masquerading servi ce s 





/ 

Security Policy 

\ 


Protection against unauthorlted disclosure 


Second-order concern: 
Confinement channel* 
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Exaaiplc of • Linear X Set 
Lattice - Military Policy 


TCB Fanctioaa 


Em6Wi i Mtvr ium 


Control »tat« DaAtWoM 


Bind Mtun tyiwm to mitmI 


C Flow Control Modsl — ^ 

Security Modsl 


Subjects and objects are assigned security levels — SL( ) 

Axioms: 


Simple security condition: 

A subject can read an object iff 

SUsubject) SLiobject) 

• - Property . 

A subject can write an objeci Ilf 

SL| object) SLlsubjeci) 

Activity: 

Only objects (hat are active 
can be accessed 

Tranquility: 

The SL of active objects cannot change 

Erasure: 

V 

When an object becomes Inactive 
its contents mutt be erased 

J 


Establish a Secure State 


Plan of Talk 


TCBa and Operating Systems 

Defining the protection policy 

Developing the TCB software 
Functions 

Design Methodology 


Control State Transitions 


Processes 

Create delete 
Sleep 

Send receive IPC mesa age 
Get set statu* 

Storage 
Create delete 

Grant revoke ownership access 
Read twite data 
Get set status 

1 O 

Create delete 

Grant revoke ownership access 
Read write device 
Get set status 















































General Purpose Thu ee haring 08 


Software Interface Fenctiona 


John ?. L. Woodward 


The MITRE 
Corporation 


Some have m 
File Syetrtn 
Dircctotv or*a« 
OWi reuident 
Media not mov 
I/O device* 

Tape. 
Terminal, 
line printer. 


TCB Software Interface Function. 


General Rnrpoae Timesharing OS 


Sa c a t M y policy aaforcad 

Lattice model applied to mtyccti and object. 

Subject* Object. 

Uem File, (dtrectortc*. etc) 

Proc eases I O device. 

ProccMe. 

Security level: jdaeelBcatton. category *ei> 

PoMcy Rule*: Simple aecurtty condition 
• - Property 
Tranquility 
Activity 
Eramire 

Procewe. can have privilege, to violate poMcy rule, 
or perform spec 1*1 lunettona 


General Design Constraint. 


T«F|M OS 

P wl.i a . tr rnnatraiwir 


r A 

General Purpose Timesharing OS 

Security policy rate. 


Simple security condition: 

A lubject can read an object !i 

SL< subject I t SUobject) 

• • Property 

A subject can write an object HI 

SU object) i Sl.ltubject) 

Activity 

Only object* that are act He (that e*Wi> 
can be screwed 

Tranquility 

The SI ol active object, cannot chant* 

E.r suite 

V 

When an object become. Inactive II* deleted) 
ttt content. muM be erased 
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Top Level Specification 


Information Flow Security Verification 


>= 


_ 


1. Identify objects Mid "seslgr" acoirtty levels 

2. Identify information flow and generate condition tablet 

3. Generate tecuiity Inequalities (LEMMAS) 

4. Prove that LEMMAS are aatfeAed 




Non-Procedural Specs 


O-function exchange (A. B) 
EMactt 
A • 8 
B • A 


fn©w Table for IPC-Sead 


i Condition 1 

Flow From 

Flow To ' 

_J 





Lemmas: 


5 U sender) SUreceiver) Not cn>* 




Example Top Level Specification '^1 


O-Function IPCSendi receiver. msfl) (sender 1 

Elects 

IPC-MSGl receiver) » msg 


[ Object 


f Secure IPC-Send SpuiflcatioB 


O-Function )PC-Sewd(receiver, m eg) [sender) 
Exceptions 

SU sender) « SUreceiver) 

Elects 

1PC-MSG(receiver) ■ meg 
















New IPC-S«nd Specification 


O-Fonction IRC Send< receiver. m*g>|*ender) 
Exception* 

SUaender) SU receiver) 

IPC-MSG<receiver) > NULL 

Effect* 

TPC-MSG(r*ceivet) » m*g 


Parameter* 
IPC-MSG< receiver) 
Exception-Statu* 
SUaender) 

SU receiver) 

NULL 


SU tender) 
SU receiver) 
SL(aender) 
Low 


( -^ 

Flow Table for New IPC-Send 

‘Condition 


SUaender) SU receiver) and Parameter* ' Exception Sta«« i 1 

IPC MSCWrecetveil a NUU. 

SUaender) SUaender) 

1 

SUaender) 

Low 

SUrecelver) 

Low 

NUU 

Low 

IPC -MSGi receiver) 

SUrecelver l 

Lemmas 

SUaender) SUaender) 

Low SUaender) 

SU receiver) SUaender)-— 

V 

Not true 

> 


Flow Table for Secure IPC-Seud 


Solutions to IPC-Send Insecurity 


Wk» tending m e ssage* only lo processes at the same level 
Build 2nd exception into an IF statement In EFFECTS: 

O-Function IPC-Sendireceiver. m*g)(*ender| 

Exceptions 

" SU tender) t SU receiver) 

Effect. 

if IPC-MSG IreceH.r) = NULL then (PC-MSG (receiver) 

«meg 

Block caller until mag can be aeni 
Acknowledge channel 
Delay before returning and audit 


Flow Table for Secure IPC-Send 


Major Functional Areas 


Condition Flow From i Flow to 

SUaender) • SL (receiver) .Parameter* Eacepitn;.-Status 

| SU tender) SU tender' 

SLl tender) IPCMSGi receiver) 

| Low SU receiver) 

: SU receiver) 

L_ l"”! _I .. _i 

Lemma* 

SLI sender) SL( tender) 

SI (tender) SUrrce ver) 

Low SUaender) 

Low SU receiver) 


Process management 
File management 
Device management 
Mtacellaneoue function* 


















Trusted OS Developments 


MITRE braasboard II 45 kernel 

MITRE/Honeywell secure MULT1CS (Project Guardian I 

UCLA dal* secure UNIX prototype 

MITRE Secure UNIX prototype 

SDC KVM 370 

FACC KSOS 11 

Honeywell KSOS 6 (SCOMP) 
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Major Functional Aruu 


Flk management 


Device management 


Miscellaneous functions 

V_ 
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Process Management 


Create* the abstraction of proe***** 

Suppont the object type: proce** 

Type* of processes 
Unprivileged 
Privileged 

Types of operations on processes 
Process creation deletion status 
Process virtual memory management 
Process switching scheduling 
Inter-process communication 11 PC I 

V___ 
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Basic TCB Architecture Options 


Internally multiprogrammed kernel 


Internally multiprogrammed kernel and 
trusted processes 


Non-interruptible kernel and truated processes 
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Process Privilege 


Examples 

Violate security model rules 
Call cenaln TCB functions 
Chang* certain object attribute* 
Set time-of-day clock 
Grant and revoke privileges 

Principle of least privilege 


Privilege • 


a • verification 
























































Inter-Process Communication 
Function* 


Mnagt function* 
IPC-Sendfproce**. m*g) 
IPC-Inquire! ) 
IPC-R*ceive< ) m- m*g 
IPC-WaM l 


•end mttugt to another proem 
check H any message* lo receive 
receive a memge 
Walt for a mnMge 


Semaphore function* 

IPC-P! semaphore) 
IPC-V(semaphore) 

Software Interrupt function* 

J PC)n (cm/pr( channel) vend 


wait on semaphore 
poat *emaphore 


I PC - A U© wic hannet) 
IPC -Ignore! channel) 
IPC-Recetveichannell 


Interrupt on a 
particular channel 
allow Int* on a channel 
ignore Interrupt* on a channel 
receiving interrupt I* implicit 


Sharing portion* of virtual memory among proce**e* 
Segment function* - «er up »hared memory 
Above function* — synchronisation 


> 


Directories of Files 





r± '[] “□ 


OiaccTOAict a fn.es A.O't 
Alfl AC<M 

AC ACC 

ATD A !%m 

•JO* tJ%K 

ArtC 
MUM 


Major Functional Areas 


Process management 

Flic management 


Device managemem 
MtaccflaneouA function* 
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File Management 


OS goal directories of We* 


nu 


TCB goal: protect info In Me* 
TCB venua non-TCB option* 
V Kernel vctu* TP option* 


File Management 




OB goafc d h aci a d** of Mm 

Security policy option* 

TCB Goal protect info In We* 
TCB versus non-TCB option* 
Kamel ver*u* TP option* 



Example function* 


Example function* 






























File-Open: 

Example Specification 


Role of TCB in I/O 


The TCB muat. 


O-Functkm flic-open (flic-name. mode^caUer] —— Ale-descript or 
Exception* 

FT {flic-name )e*i*t* a false 

- (FT(flle-name).level < PT(csller).level'and read C mode 
{PT(caller).level < FT(flie-name (level land write c mode 

Effect* 

I Assign net* lie descriptor that aaaociale* 
the gtven Ale with the requested access mode) 




If hardware 
provides... 



Non-DMA 

DMA 

No 1 '0 access control 

Interpret all I/O 

Interpret all I/O 

Access control to 

Setup Initial binding 

Interpret all I/O 

devices 

between process and 
device 


Access control to 

Setup Intial binding 

Setup Initial binding 

devices and control 

between process and 

between process sod 

of device's access 

device 

device 


to memory 


V 


Major Functional Areas 


Process management 
File management 
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Device Management 


Security Issue* 

Kama! va. TP era. (Jatrmatad software optlos* 


Device manage men t 
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Access Level 

Activity 

Access Control 

Address Space 

Attention Character 


Category Set 


COMPUTER SECURITY TECHNOLOGY GLOSSARY 


The combination of the security level 
and the Integrity level of a subject 
or object. 


The security model rule that states 
that only active objects can be 
accessed. Once an object is made 
inactive. It cannot be accessed unless 
It is made active again. 

A strategy for protecting objects from 
unauthorized access. 

The virtual memory that can be 
addressed by a process. The maximum 
size of a process’s address space 
is usually a function of the 
underlying hardware. 

In TCB design, a character that, if 
entered from a terminal, tells the 
TCB that the user wants a secure 
communications path from the terminal 
to some trusted code to provide some 
type of secure service for the user, 
such as logging In or logging out. 
Contains authorization information 
defining how the object may be used 
(e.g., read, write). 

A category set, part of a security 
level, is a list of information 
categories applicable to an object 
or subject. Categories correspond 
roughly to the topic area of the 
Information. A subject must be 
cleared for all categories on an 
object to read the object. (See 
compartment.) 
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Channel 


A means of transferring Information 
from one object to another object. 


Classification 


Clearance 


Compartment 


Concurrency 


Confinement 


An access token usually associated 
with an information repository, or 
object, though sometimes associated 
with subjects also. The 
classification of a subject or object, 
along with a category set, makes up 
the security level of an object. 

An authorization allowing a person 
(or his surrogate within a computer, 
a process) access to classified 
Information. A clearance is 
represented as a classification in a 
security level. 

Compartments are a mutually exclusive 
way to assign categories. If an 
object is compartmented, then it 
generally has only one category, 
called a compartment. Compartments 
are used mostly in the Intelligence 
bomnunlty. They are Implemented In a 
kernel-based system using categories. 

The occurrence of two or more 
operations at the same time. A kernel 
is said to have concurrency If 
interrupts are enabled to allow 
Interruption of the execution of 
kernel operations. Concurrency In a 
kernel has an adverse effect on the 
ease of verification of the kernel, 
but Increases the functionality of 
the kernel. 

A condition where a process is unable 
to leak information Illegitimately. 
Because processes must share computer 
resources, confinement channels 
are difficult to avoid. Such channels 
can be exploited to allow unauthorized 
read access to information. (See 
channels, legitimate, illegitimate, 
covert, storage, and timing channels.) 










Covert Channel A confinement channel Involving 

colluding processes. It results from 
the shared use of common limited 
computer resources. 

Denial of Service The prevention of authorized access 

to a computer system. 

Discretionary Security The aspect of security policy 

policy implementing the 

"need to know" requirement for access 

to information. 

DoD Security Policy The complete body of law, regulations 

and policy concerning the safeguarding 
of Defense sensitive information. DoD 
security policy includes all the 
Espionage laws, the DoD regulations 
and DoD authorized commercial 
classification, for handling and 
access to information concerning 
national defense. The basic policy 
set four levels and several categories 
of non-discretionary information 
control and requires that anyone 
accessing classified information have 
the need to know the particular 
Information in question. A 
representative description of the 
policy can be found in AFR 205-1. 

Domain 

Domains allow hardware features to be 
restricted or subsetted. For example, 
DEC PDP 11/H5 or 11/70 has three 
execution domains: kernel, supervisor, 
and user. The kernel domain is 
the most privileged, and allows access 
to all hardware features including 
memory maps and I/O; the other domains 
do not allow these privileges, but 
allow access as controlled by the 
kernel domain). 










Emulator 


Erasure 


Euclid 


Finite State Machine 


Flow Control 


Formal specifications 


That portion of a secure, kernel-based 
system that creates an operating 
system compatible environment out of 
the environment provided by the 
kernel. In the case of KSOS, the 
emulator maps the kernel environment 
into the UNIX environment. 

The security model rules that states 
that an object must be "erased" before 
being activated. This means that all 
objects have a precise, pre-deflned 
value when created (e.g., all zeros). 

A Pascal-based higher order language 
designed to facilitate verification. 

An abstract concept on which a 
number of protection models are based. 
In theory, by starting with a secure 
initial state and following the 
model rules for all changes, then all 
states of the machine are secure. 

A strategy for protecting the contents 
of information objects from being 
transferred to objects at improper 
access levels. 

See Top-Level Specification. 


Granularity Granularity of protection refers to 

the size of the smallest protectable 
unit of information. In a kernel- 
based system, this would be the size 
of the smallest protectable file or 
portion of virtual memory. 

GYPSY A formal program specification 

’ ' language and a verifiable high order 

language, developed by the University 
of Texas, designed in conjunction 
with a complete verification system. 






Higher Order Language (HOL) A computer language which is 

syntactically and semantically much 
richer than assembler level languages. 
HOL's are translated by a compiler or 
processed by an interpreter to produce 
executable code or direct execution 
(interpreter) on most machines, 
although some machines have hardware 
interpreters for a specific HOL. 

Hunan Interface Function A TCB operation that requires human 

intervention or judgment. Untrusted 
processes would not be able to Invoke 
them. (See Software Interface 
Functions.) 

Illegitimate Channel A confinement channel whose presence 

was not intended. (See legitimate 
channel, confinement.) 

Integrity The mathematical dual of security 

that provides protection against 
unauthorized modification of 
Information (as opposed to 
unauthorized reading). Whereas higher 
levels of security restrict the 
dissemination of information to 
smaller sets of users, higher levels 
of integrity restrict the access to 
commands and capabilities to smaller 
sets of users. 

Integrity Level The combination of an integrity 

classification and a set of integrity 
categories. 

Integrity *-property A rule of the MITRE integrity model 

that controls reading of information. 
The integrity level of a subject must 
be less than or equal to that of an 
object to read the object. 
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Inter-Process Communication (IPO 


Communication between two different 
processes. 


Legitimate Channel 


Machine language 


Mandatory Security 


Modula 


Module 


NKSR 


A confinement channel whose presence 
was not intended. (See confinement, 
covert channel.) 

The actual sequence of (usually) 
binary bits which are interpreted by 
the hardware of a computer to perform 
a program. 

The same as non-discretionary security 
below. 

A Pascal-based higher order language 
designed to facilitate verification. 
Used by FACC for KSOS. 

A collection of functions which 
perform operations on and give state 
information on one component of an 
abstract machine. 

Non-Kernel Security-Related software 
is software that, although related to 
the security of the overall system, 
is more convenient to execute in the 
environment provided by the kernel, 
as opposed to running as part of the 
kernel itself. NKSR software usually 
needs privileges to violate some of 
the kernel-enforced security rules. 
(See privileged process) 
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Non-dlscretionary 


Object 

Pascal 


Privileged Process 
Process 


Security The aspect of DoD security policy 

which deals with security levels. 

A security level is comprised of a 
security classification and one or 
more categories of access restriction. 
Classifications are totally ordered 
while categories are partially 
ordered. To access a piece of 
Information, a user must have a 
classification greater than or equal 
to the classification of the 
Information, and at least all the 
categories of access restriction of 
the information. The classification 
and categories of information and 
users are seldom changed and the 
accessibility of information by users 
Is easily checked mathematically, 
without discretion. 

The mathematical model abstraction of 
a repository of information in a 
computer system. 

A popular higher level language for 
which compilers exist on several 
machines. While Pascal was designed 
on a general purpose language for 
ease of writing correct programs, 
there have been improvements and 
extensions, especially for system 
programming, developed for several 
machines. 

See Trusted Process. 

A process consists of a unique address 
space containing Its accessible 
program code and data, a program 
location for the currently 
executing Instruction, and 
periodic access to the processor 
in order to continue. Unlike 
a program, which Is a static 
entity, a process is dynamic for 
It can change the programs In 
its address spsce. 
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Reference Monitor 


Secure Path 
Security Kernel 


Security Level 


Security ‘-property 


Security Violation 


A concept of control within an 
abstract machine that limits the 
access by subjects to objects. 

A security kernel is an implementation 
of a reference monitor for a given 
hardware base. 

See Trusted Path. 

A mechanise ilthin a computer system, 
comprised of hardware and software, 
that controls the access of users 
(and processes executing on their 
behalf) to repositories of information 
resident in or connected to the 
system. TCBs have been Implemented 
using security kernels along with 
trusted processes. 

The combination of a classification 
and a set of categories that controls 
non-discretionary (mandatory) access 
to information, (i.e., unauthorized 
(read) access vs. unauthorized 
modification (write). 

The security model rule that prohibits 
a subject from writing an object of 
lower security level. 

The infringement or breach of a 
security rule. 


Simple Integrity Condition An integrity rule that controls 

writing of information. A subject 
must have an integrity level greater 
than or equal to that of an object 
to write the object. 

Simple Security Condition The security model rule that prohibits 

the access by a subject to information 
of greater security level than that 
of the subject. 
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Software Interface 


Storage Channel 


Subject 


System High 


System Low 


System Utility 


Timing Channel 


Function A TCB operation that can be Invoked 

by software, as opposed a person at 
a terminal. (See Human Interface 
Function.) 

A channel Implemented In software that 
does not exploit the concurrent 
execution of two or more processes. 

A direct storage channel uses the 
storage associated with a kernel 
protected Information repository 
(object). An indirect storage channel 
uses other Information associated 
with kernel objects, such as control 
Information. 

The mathematical model abstraction of 
a person, process, or other user of 
information in a computer system. 

The highest level in a system, used as 
in "system high security level" or 
"system high integrity level". 

The lowest level in a system, used as 
in "system low security level" or 
"system low Integrity level". 

Any software, not part of the verified 
operating system, used to perform 
various functions that are not 
directly part of the applications. 
Examples are compilers, debuggers, 
editors, and loaders. 

A channel Implemented in software that 
exploits the concurrent execution of 
two or more processes. 
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Top-Level Specification (TLS) 


Tranquility 


Trusted Computing 


Trusted Path 


A description of the externally 
observable behavior of a system 
devoid of Implementation detail. 

The top-level specification of a 
security kernel precisely defines the 
behavior of the security kernel 
observable outside the kernel domain 
(at the kernel interface). 

For some verification methodologies, 
it is an unambiguous description of a 
finite state machine, written in a 
machine processable language with a 
well-defined syntax and semantics. 
Computer readability of the 
specifications allows for automation 
of various phases of verification. 

It is also called formal 
specification. 

The security model rule that states 
that the security level of an active 
object cannot change. 

Base (TCB) The totality of protection mechanisms 

for an operating system. It provides 
both a basic protection environment 
plus additional user services required 
for a trustworthy turnkey system. 

TCBs have been implemented as 
a security kernel and trusted 
processes. 

A connection between a user at a 
terminal and some verified (secure) 
code that is maintained only by secure 
code. Use of a secure path assures 
a user that the intended function 
will faithfully be presented to the 
code that executes the function. 

A secure path is achieved by the user 
by striking the attention character 
at a terminal. Also called secure 













Trusted Process 


Verification 


Virtual Space 
UNIX 


Untrusted Process 


•-Property 


A process that Bust be "trusted" to 
execute as specified if system 
security is to be maintained. A 
process is best afforded this "trust" 
through verification. Trusted 
processes are sometimes used to 
execute NKSR software. They are also 
often endowed with "privileges" 
to violate kernel-enforced rules. 

The process of mathematically proving 
that a mechanism behaves in a 
specified manner. In this context, 
verification is taken to mean the 
mathematical proof of correctness of 
a software system (e.g., the security 
kernel). 

See Address Space. 

A general-purpose time-sharing 
computer system designed to provide 
a good environment for a user to 
develop and operate information 
processing and computation systems. 
UNIX is a trade/service mark of 
Western Electric. 

A process whose incorrect or malicious 
execution cannot effect system 
security. (One that has not been 
subjected to verification.) 

See Security ^-Property, Integrity 
•-Property. 
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